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“Packet Radio Overview and Prospective® will 
be the subject of the December 2nd North American 
Teleconference Radio Net (TRN). This net, heard on 
over 158 gateway stations (mostly VHF repeaters) 
across the U.S. and Canada and on the OSCAR 106 
satellite, will explain what packet radio is, 
describe how to get started in it, point out the 
benefits to you, and outline the pitfalls to be 
avoided for both the novice and expert alike. The 
speakers on this TRN will be none other than Lyle 
Johnson, WA7GXD, and Harold Price, NK6K. 


Lyle is President of the Tucson Amateur 
Packet Radio Society (TAPR) and was the primary 
developer of the TAPR terminal node controller 
(TNC) hardware. For his work in developing the 
TAPR TNC, Lyle was awarded the 1984 Technical 
Excellence Award at Dayton. Looking to the future, 
Lyle is responsible for the processor design for 
the upcoming amateur packet satellite (PACSAT). He 
became active in packet radio in 1981, the pioneer 
days for this new technology. 


Harold is a Director of TAPR and was on the 
team that designed the software for the TAPR TNC. 
He is also the AMSAT Project Manager for PACSAT. 
Harold is another packet radio pioneer, having 
first become active in that technology in 1982. 


Packet radio offers opportunities for both 
the traditional communicator and for the 
experimenter. Learn about packet radio from two of 
its leading developers by tuning into TRN, Sunday, 
December 2, 1984, at 6:00 p.m. CST (that's 99682). 
For a complete list of gateway station locations 
and frequencies write the TRN Manager, c/o Midway 
Amateur Radio Club, P.O. Box 1231, Kearney, NE 
68847-1231 (S.A.S.E. please, Canada excepted) or 
check the CompuServe "Hamnet” XA4 Database. 


The FCC has assigned an RM number to a 
petition to allocate 216-222 mhz (including of 
course the bottom 2 mhz of the amateur band) to 
land mobile. This confirms speculation based on 
Robert Foosaner's (FCC Private Radio Bureau Chief) 
comments at the ARRL National Convention. 


Needless to say, this is a grave development. 
We NEED that spectrum, particularly for packet 
radio linking. There is nowhere else to go for the 
high speed FSK links that are being built right 
now." In particular, amateur satellite gateway 
stations NEED 228 mhz as all current and future 
satellites use all of the other VHF/UHF bands and 
the gateways have to operate in full duplex. 


It is becoming pretty clear that this attack 
is at least partially based on the rejection of 
no-code: the FCC considered no-code to be the 
amateur's “last chance" to populate the bottom 
part of the band. It is quite ironic that the 
ones who get hurt by this proposed change (the 
technically oriented packeteers) are mostiy the 
ones who argued FOR a no-code license to increase 
technical experimentation. 
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NOMINATIONS 


The Tucson Amateur Packet Radio Corporation 
is overseen by a Board of Directors elected by the 
membership. Currently, there are fifteen 
Directors, each of whom serves for a three year 
term. The terms are staggered so 1/3 of all 
Directors, or five in the present case, are 
elected every year. This lends long term 
stability to the organization while allowing the 
members to have a direct effect on the affairs of 
the corporation by their annual vote. The actual 
elections take place during the Annual Meeting 
held in Tucson every Pebruary. 


Nominations are now open for the five slots 
that must be filled this coming Pebruary. The 
procedure is quite simple. Either you, or someone 
you can convince, submits your name for 
consideration. If someone else does it for you, 
you will be contacted and asked for a brief 
description of yourself for publication in PSR. 
You will also be given the opportunity to withdraw 
your name from consideration. 


We expect to publish the names and 
qualifications of all candidates for Director in 
the next PSR. In addition, the issue will also 
contain a ballot for you to select five names and 
mail in, og bring with you to the annual meeting 
when the votes will bea tallied and the results of 
the election announced, Pollowing the meeting, 
the new Board of Directors will meet and elect the 
Officers of the Corporation who will then serve 
for one year term. Simple, eh? 


Directors are expected to play an active role 
in TAPR by advising the Officers, expressing their 
opinions on the issues we face and generally 
helping to see that TAPR continues to be the 
leading organization and motivating force in 
packet radio by its research, development and 
information dissemination efforts. 


Please consider this matter carefully and 
Place your nominations now. T£ you know the 
person you are nominating (and don't nominate them 
if you don't), please include a short description 
of the nominee. Time is very short for this if the 
information is to be included in the next PSR 80 


DO IT TODAY! 


On Monday July 16, 1984 at 7:45 AM PDT, 
Curtis, N6ECT transmitted packets to 50 states and 
half the world, all at the same timel 


Serious packeteers might wonder how this 
feat was done, so here is the scoop. N6ECT was 
interviewed by the CBS Morning News show as part 
of a piece done on the Haight/Ashbury 28 years 
later. As the interviewer introduced Curtis, 
they focused on some 2306Mhz antennas near his 
home, and then on his ICOM 211 and CRT, just as 
he was transmitting packets through the KA6M-2 
repeater. A packet burst was heard loud and clear 
right before they asked him their first question. 


President’s Corner 


by Lyle Johnson, WA7GXD 


There is plenty of excitement in Tucson this 
month! TAPR now has an office, a warehouse, a 
telephone and an office manager! 


The volunteer corps was rapidly decaying into 
a volunteer corpse -- mail has run as high as 8? 
Pieces in one trip to the PO sox, five different 
people were assisting with membership services and 
other mailbox-related activities, organization was 
difficult and... you get the picture. 


In addition to the sheer person-power and 
inefficiencies of having things scattered across 
town (Tucson is 1/2 million people and hundreds of 
square miles large), storage space at folks‘ homes 
was being usurped in alarming proportions. Some- 
thing had to be done. 


After consultation with the TAPR Board of 
Directors (your elected representatives), your 
Secretary and President began to search for office 
space -- and an office person to offload the 
burden of day-to-day administration of TAPR. 


I am extremely pleased to report that these 
efforts have been successful. Elsewhere in this 
PSR you will find the telephone number. The 
pleasant voice on the other end of the line will 
(usually) be Karen Makus, your office manager. 


So much for what the office will do for your 
vOlunteer staff. What will it do for you? 


Within a couple of months (more or less, 
depending on how the transition and training 
period progresses, the new database management 
system integrates, etc.), you should see that 
membership renewal reminders are sent in a timely 
manner. This should help you keep your membership 
current. 


Kit orders should ship within two working 
days. We are planning on daily UPS pickup service 
with a reasonable inventory of TNCs for immediate 
delivery. 


Parts orders, for both mod kits and 
replacement usage, should likewise ship in two 
working days. 


We will be able to accept telephone orders 
for kits/parts/membership along with VISA/ 
MasterCard payment service (at a 3% surcharge -- 
this is what they charge us). 


Inquiries via mail should get immediate 
response to general questions -- however, Karen is 
NOT a technical guru, so volunteers will have to 
answer your technical questions, meaning 4 to 6 
weeks for a reply. 


What other benefits may accrue? With the 
offloading of the day-to-day affairs of TAPR, some 
of your more technically inclined volunteer staff 
based in Tucson may find more time to get on with 
packet radio! 


This is not to imply that there is nothing 
happening now, nor that Tucson is where it all 
happens. 


For example, Steve Goode, K9NG, has been 
quietly working on a 9608 bps TNC-to-antenna 
“modem” and is now testing the design. With a bit 
of luck, we should be verifying his results and 
getting ready to find a means to get it in your 
hands after a bit of testing. So, high speed 
modems are in progress. 
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On another front, the powerful TiNC LiNC -- a 
black box designed to handle multiple protocols 
(AX.25 Level Two, RTTY, AMTOR -- maybe even Cw!) 
on different channels SIMULTANEOUSLY, and at high 
speeds (maybe 56 kilobits per second!) is in final 
“alpha” design. Before year's end we should have 
several units operational and _ than... but I 
suppose I had better not let the whole cat out of 
the bag! Incidentally, this design is based in 
San Diego (responsibility for primary hardware 
design lies with Mike Brock, WB6HHV and a TAPR 
Director), with hardware design review assistance 
from TAPR packeteers in Arizona, Florida, 
Illinois, Missouri, Colorado, New Jersey... the 
list goes on. 


I hope you can see from these two examples 
(yes, there are others, but if I tell them all 
now, I might run out of material for the next 
PSR1) that TAPR is not simply a means of 
disseminating developments from Tucson to the rest 
of the Amateur packet communitgy: rather, TAPR is 
a means for packeteers from all over to _ share 
ideas, participate in development and cooperate in 
implementation of packet systems for the benefit 
of all Amateurs. 


One point that I try to stress in my travels 
is that TAPR is not out to dictate to one: we 
pee ie soe oe ae, 


are here to serve everyone and act a focal 
point for ideas, a coordinator of efforts if you 
will. One way this can be brought about more 


efficiently is if YOU write to us, mark the 
envelope “For PSR", and let us know what is going 
on in your area. Multifrequency digipeaters, how 
many folks are on in what areas, what frequencies 
are used, what BBS systems are up, what programs 
work with the TNC on what computers, how you 
solved the why-the-TNC-goes-in-the-woods-when-300- 
volts-is-applied -- you get the idea. We want to 
help you share your packet experiences with 
others. Please write... 


KKKKKICK 


David Henderson, KD4NL, one of the authors of 
the software running on your TAPR TNC, has 
rewritten the Pascal code for the TAPR TNC to run 
on an 18M PC (or clone). Dave's code duplicates 
the TNC environment: the command structure, the 
monitor mode, etc. on the PC and runs a simulated 
HDLC/radio link. Operationally, you “connect” to 
yourself, then watch what’s happening via monitor 
mode, play with link timings, etc. 


One major goal the software package addresses 
is that of protocol development and 
experimentation. If you want to try changing the 
code for various enhancements, or just better 
understand how your TNC works -- and if you have 
an IBM PCI <= this package may be just what you 
have been looking for. 


System requirements are: IBM PC (or clone), 
192k bytes RAM, FC DUS 2.6, IBM PC Pascal. Send a 
stamped, self-addressed diskette mailer, with 
formatted DS/DD system diskettee to: 


Adroit Software Products 
2210 Wilshire Blvd, Suite 773 
Santa Monica CA 90483 

ATTN: AX25 Software 


This ie a "user-supported" experiment, 
meaning that you can copy and distribute the code 
as you wish. If you find it of use, a suggested 
contribution is requested. Contact Adroit 
Software for further information. 
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Packeting In The Fast Lane 


by Lyle Johnson, WA7GXD 


“Hmmm. Why is it that I haven't heard from 
anyone using the high-speed clock option on the 
TNC?" I mused to myself one summer day. "Come to 
think of it, why haven't I heard from me!“ 


With that, I rushed to the laboratory (the 
lair of bearded fanatics...) and grabbed the 
"scope, counter, terminal and TNC. 


Step one was to verify the operation of the 
TNC. This was done using the famous WA7GXD analog 
loopback mode (a piece of wire from radio 1/0 
connector J3 pin 3 to J3 pin 5 -- works great 
since the TAPR TNC is a full-dupiex machine!). I 
connected to myself via myself as eight digi- 
peaters, then sent beacons the same way. 


Satisfied that all was working well, 1 
consulted the TNC schematic and removed the 
jumpers at J5 pins 17-18 and 19-26. I then 
installed a jumper at J5 pin 17-19. This effected 
a digital loopback, where the TTL-level transmit 
data output from the HDLC controller was simply 
connected to the TTL-level receive data input. T 
then connected to myself and saw that this mode 
indeed worked. This is a handy way to isolate the 
@igital circuitry from the modem in case of 
troubleshooting. 


Cautiously, I entered the command mode and 
set HBaud to 4800. I then connected to myself, 
digipeated through myself, and did all manner of 
exercising of the link -- it worked flawlessly! 


Pleased with this outcome, I removed power 
and set the jumper at JP7 to the high-speed side. 
This means that the system clock runs at 1.8432 
MHz and the system timing parameters are all twice 
as fast as normal (all but the serial port -- it 
has its own hard-wired tap on the clock circuit so 
the ABaud rate remains sensible!). I powered it 
up, and lot it worked fine! The 1 Mhz chips 
forgot that they weren't supposed to be the 2 MHz 
parts, the EPROMs decided to access okay and the 
peripheral parts just seemed to love it! 


At any rate, the CWID was now about 40 WPM (I 
then disabled it), and the system was running just 
fine at 9600 baud on the radio lLinkl 


After I calmed down, I set the TNC up at the 
normal clock rate and hooked up an external clock 
(remove J5 jumpers at pins 11-12 and 13-14, jumper 
35 11-13, apply a TTL-level square wave at J5 ll- 
13), and verified that the TNC worked. 


The next step was to see where it fell apart, 
so I kept monitoring a long beacon text sent 
unproto via myself three times (UNPROTO CQ VIA 
WA7GXD, WA7GXD,WA7GXD) and cranked up the data rate 
on the HDLC controller. I get the terminal port 
to 19,206 Baud just to keep the 6869 busy with 
output. I even turned trace on to $FFFF! 


The unit kept up quite well at 4802 baud 
under all of this abuse (there was some delay in 
between digipeated frames due to all the 1/0, but 
not much). At 9688 baud, the TNC would usually 
copy the first packet, dump it to the screen, and 
forget to digipeat. Playing around with the 
DWAIT, TXDELAY and FRACK parameters didn't help. 
Varying the frequency of the function generator 
(and thus, the HBaud rate), 1 found the TNC would 
handle things just fine until the data rate got to 
about 9408 baud <-- then it would get the first 
packet, but wouldn't digipeat it. If I turned 
trace back onto S$FFFF, the top limit dropped 
slightly to about 9108 baud, and the delay between 
digipeats extended considerably. Of course, that 
most d@igipeaters don’t have trace on $FFFF: that 
adds a tremendous load on the 1/0 system! 
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I also found that, if I left a Control-S on 
the line (XOFF <= tells the TNC to not send data to 
the terminal port), the TNC would happily digipeat 
all three times at 9600 baud - it worked okay past 
18,080 baud but never copied a packet by the time 
I reached 11,000 baud. The XOFF trick doesn't do 
much good if TRACE is left at $FFFF, so I set it 
back to the default ($1080). 


If 1 watched the LEDs, and sent a Control-Q 
(XON - tells the TNC to go ahead and ship data to 
the terminal port) after the digipeats were 
completed, ali four monitored frames were in the 
buffer waiting for me. 


I repeated the experiments at the double 
clock speed and found the TNC was quite happy to 
do a multiple digipeat at over 28 kilobaud with 
terminal 1/0 at 19.2 kilobaud «= it just kept on 
playing as long as I cared to watch it. 


The net result? We have a (nearly) 9680 baud 
TNC with the normal clock rate and a better than 
19,288 baud TNC at double the normal clock rate -- 
using standard parts! 


I would be interested in hearing from as many 
of you as possible as to whether your TNC works 
Okay with the double speed clock (if you put it on 
the air, use HBaud of 608: this will be 1200 
actual, and be sure to use double the normal 
parameters for DWAIT, TXDELAY, FRACK, etc.). A 
trick way to try the higher data rates on-board in 
digital loopback (as outlined above) is to use a 
jumper from R79 to +5 volts (this sets the HDLC 
controller to an xl rather than an x32 clock for 
the radio link) and set HBaud to 150 for 4890 baud 
equivalent, 300 for 9600 baud equivalent at normal 
clock speed, and HBaud of 75 for 4808, 158 for 
9600 and 300 for 19,208 with the twice-normal 
clock, so the function generator is not necessary. 


wKrkkiKKKk 


The Second Annual AMSAT Technical Symposium 
and the 1984 Annual Membership Meeting have been 
firmly scheduled for Saturday 16 November 1984. 
The specific day was selected following careful 
consideration of all available individual 
preference comments. 


The location will be the Amfac (formerly 
Airport Marina) Hotel at the corner of Lincoln and 
Manchester, On the north side of Los Angeles 
International Airport (LAX). The address is 8601 
Lincoln Bivd., Los Angeles CA 90045. Telephone: 
(213) 676-8111. 


Prices are moderate and major credit cards 
are accepted. A block of “corporate rate” rooms 
has been set aside for AMSAT use. Room 
reservations should be made directly with the 
hotel. 


Pacilities Chairman is Dennis Dinga, N6DD. 
Dennis will be handling arrangements for the 
Planned luncheon and dinner on the day of the 
meetings. His address is; P. O. Box 4111, 
Diamond Bar, CA, 91765. 


Dr. Cleyon Yowell, AD6P will serve as 
Symposium Technical Chairman. A call for papers 
has been issued. Submissions should be sent to 
Cleyon at: 


The Aerospace Corporation 
Mail Station M4-930 

P. O. Box 92957 

Los Angeles, CA 908009 
(213) 615-4234. 


Software Bug Patch 


by Harold Price, NK6K 


The following bugs are patched and become version 
3.3 of the TAPR TNC software: 


(1) RETRY counter is not maintained correctly in 
all cases. You may get the "retry count exceeded” 
message when you don‘t expect it. 


(2) An AX25 OFF mode only problem with beacons. 


Note: If you always run with retry @ or have 
never seen a random disconnect, and if you don't 
usually run with AX25 off, then don't work up a 
sweat getting your proms updated. A major 
maintenance release is in the works which will 
incorporate these fixes. These patches are being 
released early by popular demand. 


These patches can be applied locally if you 
have the facilities to read the current prom, edit 
it, then reburn it. The patches are to the AQZB 
prom only. The patches are the same for both the 
BETA version (3 prom set), and the KIT version (4 
prom set). The BETA and KIT proms are NOT inter- 
thangeable however, so don't get them mixed up. 


Address Current New 
Contents Contents 


Ac99 TE TE 
AC9A 15 ac 
AC9B Ds 81 
BB74 17 7E 
BB75 21 BA 
BB76 F2 33 


Once changed, the checksums (CAL command, 
menu option 5) for the A@@@ PROM will be 4C9F for 
the Revision 2 kit TNC, and SD3A for the Beta TNC. 


Due to the PSR deadline and other things, we 
haven‘t got enough time to document the checksums 
for all the post 3.1 release patches BETA and KIT. 
This is one of the reasons why we wanted to avoid 
patching, but we feel the retry bug is painful 
enough that here it is. In any case, none of the 
previous patches has been to the A@@® rom, its 
checksum should be as above regardless of whether 
you have 3.1 or 3.2. The 3.2 patch added 400 and 
806 and other odd baud rates. This was for some 
AMSAT experimenters and won't be needed by 99.44% 
of TNC owners. This patch will be needed by a 
greater number, and becomes version 3.3. TNCs 
shipped after the patch is applied at the 
“factory” will have version 3.3 in the signon and 
beacon text. 


The next software maintenence update will 
probably be called version 3.4. This will be a 
change to the software and will change all ROMs. 
Unless we are very lucky and find a_ tighter 
compiler, the new software will not fit in 3 ROMs. 
Beta board owners should not despair, we should 
release hardware update procedures to get you to 
four ROMs before the software requires it. (Hint: 
I've got a Beta board). 


On August 23, 1984, Curtis, N6ECT, and Mike, 
W2FRT, exchanged packets at 9680 bps using 
quadrature amplitude modulation techniques over a 
path of five miles. We were both using personal 
computers, 9606 bps modems, homebrewed radio/modem 
interfaces, 448 MHz radios, with verticle and 
beam antennas. The software was written in Turbo 
Pascal for use with the SDLC cards in the 
computers. There were no transmission or 
reception errors and the throughput was 100% at 
10 watts, and 60% to 70% at one watt. 


KAKKKKK 
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Software Bugs 


by Harold Price, NK6K 


Since a TAPR software maintenance release 
will be out soon, I'd like to make sure we have 
all bug reports and requests for changes in. 


I'll list the ones I know about here, along 
with a disposition, if known. Please feel free to 
make comments on any part of the TNC, hardware or 
software, Please keep in mind the following 
though: 


There are now at least 1308 TAPR TNCs (Beta + 
kit) in the world today. Many people have written 
code to match the current user interface, mail- 
boxes, bulletin boards, host systems, gateways, 
etc. Ask yourself if your proposed change will 
require a change in user software. If your 
suggestion would cause recoding of other ham’s 
software, unless it has a major benefit, we would 
probably have to turn it down. This is called the 
real world, which is something you get into when 
1306 hams are involved. 


A few of the discussions below will seem long 
and involved. That is because some of the bugs 
are in more advanced features. The majority of 
the bugs in the more common features were wrung 
out in the beta test. On with the bugs: , 


(1) <If€ RETRY is not 6, the TNC will 
sometimes disconnect before the retry count has 
expired. This problem took a long time to find, 
because we couldn't reproduce it. Someone in the 
field came up with a reliable way to make it 
happen. The symptom was affected by both the 
number of frames in flight, and the number of 
frames in the buffer waiting to be sent. 


(2) TNC “locks up". This is a difficult 
symptom to trace. Most of them are caused by a 
fault in the hardware. We have found a bug in the 
software that could cause this, to my knowledge 
only one person has fallen in to this particular 
hole. This is patched along with the retry bug. 


(3) TNC prints garbage on the screen, 64K 
worth, then comes back. I have heard rumors that 
the GLB board can send a frame which causes this 
to occur when it is received by a TAPR TNC. If 
anyone has firm information on this, please send 
it in. Sometimes the rumor comes in as “The GLB 
sends an illegal protocol frame", possibly an I or 
UI frame with no PID byte. Based on that, and the 
symptom, we have fixed a problem that would occur 
if that type of frame was received. If you have 
any info on this, send it in. This will be fixed 
in the next software update: it is not patched. 


(4) The beacon is not started even if a non 
zero value for beacon time is stored in NOVRAM. 
True enough. You must give a BEACON command after 
every reset. This bug wiil be fixed in the next 
software update. 


(5) The 400 and 80@ baud rates for HBAUD 
that were there in 2.1 disappeared in 3.1. A 
patch is available for this, and has been sent to 
the AMSAT guys who needed it. They use 400 baud 
PSK thru Oscar 10. Fixed in next software update. 


(6)  *** connect request comes out in trans- 
parent mode. I can't make this happen. It will 
happen if CONMODE is CONV, you are currently 
unconnected, and you manually go into transparent 
mode by saying TRANS. When a connect occurs, you 
will go into CONVERS mode and will see all 
messages. If you want to do this, and remain in 
transparent mode on connect, say CONMODE TRANS. 
If anyone has another way of making this happen, 
please let me know. 

(continued on page $) 
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(continued from page 4) 


(7) If your terminal overruns the TNC's 
input buffer by ignoring an ‘xoff> character, the 
TNC will never try to <xoff> you again. Serves 
you right, tool This bug should be fixed in the 
next software update. See also improvement #11 
below. 


(8) TRACE 2xxx bit doesn't work. Non-header 
data is always dumped. 


(9) Autobaud is a bit flakey. Since the 
hardware has no specific baud rate measuring 
capability, an easy fix is simply to limit the 
autobaud choices to 368 and 1208 baud. If this 
would have caused a great deal of difficulty in 
getting your board up the first time, please let 
us know. 


This is the end of the known bugs, i.e. those 
things which work counter to the way we intended, 
or counter to the way things were documented. 


The following are change requests. 


(1) Store a line to be transmitted wnen your 
TNC is connected to by another TNC. E.g- CTEXT 
I'M IN THE SHOWER, PLEASE RING BELL. That message 
would be sent automatically when a connect 
occured. This stands a good chance of getting in. 


(2) Store a line to be transmitted when your 
TNC refuses a connect from another TNC. You'd 
like the other guy to see 


*** WB6UUT busy: MAILBOX IS DOWN. 


This is a little more iffy. Since the frame used 
for a connect NAK, DM, has no 1 field, we have to 
put the text in a UI frame. The connecting TNC 
would have to have MON ON, and the UI frame would 
have to follow the same digipeater path back, 
which may be a different path than UNPROTO packets 
usually take. Thus, even if you used this 
facility, you stand a finite chance of it not 
working. Is this worth the effort to implement? 
Comments please. 


{3) Link status check. You'd like the TNC 
to automatically send a frame to see if the other 
TNC is still there. If not, your TNC would 
timeout based on RETRY. The command would be 
CHECK EVERY/AFTER n, where nis aé_ convenient 
interval. It would not apply if RETRY was 2. 
This will require a protocol change or update. 
Right now, with the poll/final controversy, there 
is no way to prod the other end into iving a 
response, short of sending a zero length (PID byte 
only) Iframe. This seems a bit tacky. This is on 
the list of things to get resolved at the next 
protocol review in September. 


(4) Discard unacknowledged 1 frames when a 
disconnect occurs. Currently, if there are 
outstanding frames, i.e. frames waiting to be 
ACKed or resent, or frames that are in the 
terminal input queue but as yet unsent, we dump 
them as UI frames to the UNPROTO address list. 
This is listed under improvements because this is 
as we intended it to be, i.e. this is a feature, 
not a bug. We feel this is a useful diagnostic 
aid. WE in this paper, by the way, is various 
combinations of KV7D, KD4NL, and NK6K, depending 
on which of us is responsible for that part of the 
code. Comments on this one, please. 


(S$) Implement a TNC resident file transfer 
” protocol. When it comes to file transfers, the 
TNC was designed to be transparent, just like a 
modem. In fact, if you go into transparent mode, 
you can run any program that assumes it’s talking 
to a modem and get the desired results. (And no, 
it doesn't dial the phone on ATDT commands, wise 
guy). Note that if you want to transfer 8 bit 
data you must set the AWLEN and PARITY options 
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correctly, otherwise we'll trash the high order 
bit. Most data transfer programs will run 
correctly thru the TNC, as long as their internal 
timers can handle the inherent delays in packet 
transmission and digipeating. Implementing a TNC 
based file transfer protocol would please a small 
number of users, who would still heave to write 
code on their computer to interface with the TNC's 
file transfer mechanisn. I think the current 
scheme is the right choice, and is more in line 
with the division of tasks set out in the I5S0 
seven layered OSI model. Comments? 


(6) Confirm entry into CONVERS mode. You 
want a warm fugzy feeling that the TNC has done 
your bidding in response to the CONV command. 
This would require a change that would bother the 
mailbox/host/gateway crowd. They doa lot of 
popping in and out of command mode to check 
status, paths, and other things. An extra message 
might put the warm fuzzy message into a file, 
unless they modified their code. Comments? 


(7) Go back into command mode after a 
disconnect initiated by the other TNC. Currently, 
you are left in CONVERS or TRANS mode. This 
should not both mailbox/host types since cti-C in 
command mode is ignored. Comments? 


{8) Implement a watchdog timer. Have the 
software pulse a bit on the parallel port at some 
inner point only reached if the software is 
running correctly. This is so mountain top 
digipeaters can reset themselves if something bad 
happens. Note that this is different than the 
hardware transmit timer. Good idea, and it will 
probably be in the next release. 


(9) Print the digipeat list when: 


{a} Someone connects to you 
(b) When you get a connect request 
{c) When monitoring the frequency. 


I think (a) and (b) should be done all the time. 
(e) would add to an already cluttered monitor 
mode. Anybody see a better way of doing it. 
Adding another cammand to enable this would add to 
an already lengthy command list. MPATH has been 
suggested. 


(18) Print connect and disconnect packets in 
monitor mode. How about: 


NK6K>WBG6YMH <C> 
WBEGYMHONKGK <D> 


There are connect ACK and disconnect ACK frames, 
but that might be getting carried away. 


(11) Increase the number of bytes that the 
TNC will handle from the terminal after the TNC 
signals <XOFF>. Currently, you must stop within 
five bytes. After that, the TNC sends another 
<XOPF> after each of the following five bytes. 
After that, any characters received before the TNC 
sends an <XON> are discarded. While this has not 
been a problem for users writing file dumpers’ in 
assembler or some high level languages, it has 
been a problem for programs which dump a _ line, 
then look in their input buffer for <XOFF>. We 
will probably increase the guard space to at least 
80 characters. Anyone need more? 


(12) Output <CR> after the callsigns on 
monitor lines. This would give more room for 
digipeat paths and not break up data lines. 


(13) Echoing XOFP and XON. Currently, if 
the terminal sends a flow control character out of 
sequence {(XON before XOFF, 2 XOFFs in a_ row, 
etc.), the TNC treats such characters as data and 
echos them. This has the effect of locking some 
terminals. It has been suggested that we eliminate 
this feature and ignore those characters. 

(continued on page 24) 
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VADCG Upgrade 


by Terry Fox, WB4JFI 


The Amateur Radio Research and Development 
Corporation (AMRAD), originators of the popular 
AX.25 packet radio protocol, has developed a 
retrofit board for the Vancouver Terminal Node 
Controller board, originally developed by Douglas 
Lockhart, VE7APU. Using the daughter board (part 
number VDS-1), systems designers are now freed 
from the memory constraints of the original board. 
This translates into better operation for the 
packet radio enthusiast. 


Some of the advantages of the AMRAD Vancouver 
Daughter board system are: 


* Wo modifications (jumpers or traces cut) 
required on the Vancouver board for 
normal operation. 


* No jumper wires to hook between the two 
boards (All connections necessary are 
done via wire-wrap sockets). 


7 EPROM is expanded from 8K to 32K. 
* RAM is expanded from 8K to 32K. 


* Software programnable baud rate 
generator (using Intel 8253). 


® Optional use of timed interrupts for 
better software control. 


° Up to six l6-pin sockets, one 24-pin 
socket, and an are of 1.1 by 1.7 tenth- 
inch holes for user kludging. 


* Uses only two additional ICc’s (other 
than RAM and EPROM). 


* Requires no additional power supplies 
(the minus five volt supply needed for 
the 2706's can be eliminated) 


> Full documentation available. 


To order a VDS-1 board, send $25.88 plus 
$2.25 for shipping (US funds) to: 


Technetronics Systems Inc. 
ATTN: Charles 0. Phillips 
6134 Columbia Pike 

Palls Church, VA 220641 


Kkkkkkk 


UOSAT-2 ground controllers at the University 
of Surrey switched on the VITA/AMSAT Digital 
Communications Experiment for the first time on 
Tuesday, June 5, 1964. Current drain is within 
the range expected. The first major operational 
test of the DCE was also carried out successfully 
when the DCE was given control of the downlink 
beacon. Indications were that the ROM based boot- 
loader was active and awaiting software load 
commands from the ground. The first software 
tests are scheduled for tomorrow. These tests 
will check out a portion of the DCE's 128k bytes 
of memory as well as testing its data transfer 
functions. 


We know the bootloader is working because it 
occasionally sends a series of ‘N‘ characters on 
the downlink. This means it is running, can talk 
to the downlink, and is seeing characters on the 
uplink. Since the N's aren't steady, it means the 
input is not locked at the same character. The 
bootloader prints N's when the one byte preamble 
is not followed by correct frame headers, data, 
and checksums. 


RS-232 Problems 


by Lyle Johnson, WA7GXD 


It has come to my attention that the TAPR 
TNC's hardware flow control scheme has a big 
problem. 


If ictTs is negated (tell the TNC to stop 
sending data to the user port), the 6551 UART may 
halt in mid-character. This could cause loss of a 
character so carefully protected by the FCS, 
having hazarded its way to your QTH by a difficult 
and dangerous, and perhaps non-Level-Two, multip- 
hop path (sigh). 


This is not good. In fact, some folks’ BBS's 
and other automated operations find it to be very 
bad indeed. 


The Synertek data books are very vague about 
this, but seam to indicate that this is a feature, 
not a bug. 


The Rockwell Data Book (July, 1981) has a 
timing diagram that confirms that the 
aforementioned behavior is in fact a feature. 


However, the latest Rockwell Data Book 
(Synertek is still vague, and Commodore now uses 
the software approach in their Vic-20 and C-64 
machines), 2nd Edition, 1984, Clearly and 
specifically shows a timing diagram that 
indicates the "feature" has been changed! 


New versions of the Rockwell R6551P properly 
implement !CTS flow control by completing the 
current transmitted character before going into 
the “BREAK" condition, so you don't have to bit- 
synchronize the handshake with your “host”. 


I am checking with Rockwell to find the date 
code for the chips that implement this change 
(does this imply the previously documented feature 
was in fact a bug?) and TAPR will arrange to get a 
few of these chips for field testing. 


If they work as newly documented, a simple 
substitution is all that will be needed to make 
the hardware handshaking become civilized... 


Stay tuned... (whew! maybe we really did 
implement RS-232C correctly!itt 


KEKKKKK 


If you read the editorial by Dave Sumner in 
your June QST, then you know that the ARRL is 
going to be putting some effort toward supporting 
the growth of packet radio. In part, we have 
Paul Rinaldo to thank for this. The ARRL 
Technical Department (of which Paul is the 
manager) will be addressing many of the needs of 
the packet network. In order to complete any 
projects, they need to set some priorities, and 
in order to set the priorities, they need to know 
what people in the field are already doing. 


The ARRL would like to begin work on a 
spectrally efficient high speed (9.6 or 56 kB) 
modem. If you are already working on such a 
modem, send Jeff ward, K8KA, a message DETAILING 
your efforts. In conjunction with the modem 
design project, we will be working on RF strips 
for the high speed back-bone. 


Also, the ARRL would like to find out if 
anyone is working on audio baseband 9.6 kB modems. 
These modems exist for phone service, but it is 
unknown if the average 2-meter rig can handle it. 


Let the ARRL know what you are working on. 
and what you think they should be working on. 
And finally, send them any comments you might have 
on the proposed national packet directory. 


Cen Packet Status Register September 1984 


Crossband Digipeater 


by Mike Brock, WB6HHV 


The need to tie packet frequencies in 
different bands together came up & while back in 
the San Diego area and the solution to this 
problem may be useful to other packet LANs around 
the country. The problem is that (believe it or 
not) not everyone has a two meter radio that they 
can use for packet. And then how many times have 
you heard questions to the effect of “Why don't 
we use 226?" and the associated comments which are 
“I'm on 228 but nobody else is up there”. These 
problem can be solved in a rather simple and 
inexpensive way. Later on I'll suggest some other 
uses for the crossband digipeater. 


The idea, as previously mentioned is very 
simple and easy to implement. What you do ig to 
effectively parallel two radios on one slightly 
modified TNC. Thats all there is to it. The 
audio lines from the radios are combined in an 
Op amp mixer and then fed to the TNC. In order 
to minimize the parts required I just adjusted 
the audio output level of the TNC to the setting 
required by the radio that needed the most drive 
and then ran @ pot across the TNC output to set 
the level required for the second radio. For the 
second PTT line I just added a transistor (junk 
box 2N2222) and drove that off of the 555 fail 
safe timer (the same place the PTT buffers on the 
Beta TNC are driven from). You can put a VFET 
here if your radio requires one, but my radio 
didn't need absolute ground to key it and I didn't 
have a VFET in my junk box. I wired this 
circuitry up in the wire wrap area of the Beta 
TNC I used for this experiment. I used a ten pin 
connector to interface to the radio since this is 
the type of connector used for that purpose on 
the Beta TNCs. Now with the exception of the 
audio output level, I can use either radio on 
either connector. 


How does all of this work? It works rather 
well. The users of this special digipeater don’t 
see any difference between it and a atandard 
digipeater. To connect to a station on the other 
band he just types something like 


CONNECT WB6CYT VIA WBGHHV~2 


where WB6CYT is on the other band (or not, it 
really doesn’t matter) and WB6HHV-2 is the cross- 
band digipeater. When the digipeater sees its 
call sign in the repeat field, t will retransmit 
the packet on both bands. When WB6CYT 
acknowledges the packet, that acknowledgement is 


Audio Circuits 
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also retransmitted on both bands. The only real 
difference the user will notice is that even if 
the ham he is talking to is next door, he will 
not hear him directly. This also means that this 
digipeater is aubseptable to collisions at its 
input. This is the same digipeater problem that 
eccurs when there are users that can’t hear each 
other but a normal digipeater can hear both. The 
erossband digipeater is actually a little worse 
since this collision problem will occur with local 
stations who are on opposite bands as well as the 
typical distant station problem. Portunately, 
most of these problems will vanish with the 
introduction of level three as will the need for 
this type of device. 


One of the benefits of this acheme is that it 
allows two nets to occupy the same geographical 
area and yet not interfere with each other until 
someone specifically requests the cross 
connection. This can be very useful in areas 
where there is a lot of packet activity. This 
Gigipeater provides a cheap and dirty way to have 
two frequencies and yet makes it possible to talk 
with people on either band without having to have 
two radios/TNCs or to be constantly switching back 
and forth to find the people you want to talk to. 


Another one of the benefits is that a pair of 
these digipeaters can be used to form the basis of 
a temporary inter-LAN link. It is temporary 
because this will all be replaced by level 3 
implementations. This scheme makes use of the 
multiple digipeat extension to AX.25. The user 
would connect to the remote user by entering a 
command similar to the following 


CONNECT NK6K VIA WB6HHV-2,WB6YMH-1 


assuming that HHV and YMH are the crossband digi- 
peaters. The reason for using an alternate band 
for the link is to allow access to the adjacent 
LANs standard operating frequency. In Southern 
California we are moving to a plan where San Diego 
is on 144.760MHze and L.A. is on 145.360MHz because 
of the level of activity. The problem with every- 
one being on the same frequency is that there are 
stations that can hear both LANs and that tends to 
increase the collisions and therefore reduce the 
efficiency of the network. Splitting the LANs 
eliminates this problem but means that you can't 
talk with the hams is L.A any more. The crossband 
digipeater reestablishes the L.A. connection but 
only on demand. 


kkk 
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Meteor Scatter Connections 


by Richard Zwirko, KIHTV 


The Perseids is one of the best of the 
numerous meteor showers which occur throughout the 
year. Although this shower usually peaks around 
August llth or 12th, many contacts are made via 
the ionized trails of these meteors a number of 
days before and after the peak. At 2 Meters, the 
duration of meteor bursts can run from milli- 
seconds to a few minutes. Most of the early VHF 
meteor scatter (M/S) work on VHF was done on 144 
MH using CW as the mode of communications at 
speeds of 15 TO 35 WPM. As single sideband 
equipment became available on 2 Meters many 
contacts were made via meteor scatter via that 
mode. Voice speeds range from 25@ to 350 WPM. A 
greater signal to noise ratio is needed for SSB, 
probably between 4 and 6 DB more. 


Two Meter SSB meteor scatter contacts have 
been made by many stations 1888 miles apart 
running no more than 106 watts to a 18 DB gain 
yagi antenna. Since the transmission data rate of 
SSB is approximately 16 to 15 times faster than 
CW, a complete two way SSB contact can be made on 
meteor burnout which lasts from 18 to 15 seconds. 
Since most M/S calling sequences used by 2 Meter 
stations are 15 seconds long, it is possible to 
get a fifteen second long meteor burst and still 
not make a contact. The problem is to catch the 
meteor at the right time. 


Now along comes Packet Radio with its 120808 
baud transmissions. At 8 bits per character 
(letter), data is being sent at a rate of 
approximately 15@ characters (3@ WORDS) per 
second. Thats about 1860 WORDS per minute or about 
6 times the rate of fast human speech. In packet 
radio the actual data rate is a little lower 
because of the extra flag, address, control and 
frame checking bits needed to make packet trans~ 
missions possible. At the 1208 baud rate, the 
overhead amounts to about 138 to 158 milliseconds 
per packet or an effective data transmission rate 
of over 128 characters per second or about 25 
WORDS per second. Thats still really moving 
compared to CW or the human voice. 


Almost all of the voice 2 Meter M/S work in 
the past has been done on Single Sideband. Since 
stations can’t hear each other until a burst is 
heard and since that burst will probably be very 
short, tuning in a SSB station to within 100 Hz is 
not very easy to do. With packet radio, the tones 
going into its modem have to be within about 100 
Hz of the required frequency. Once the frequen- 
cies have been set properly at both ends of the 
path there is another problem to be faced and that 
is one of doppler shift which occurs on many 
meteor bursts. By using Audio Frequency Shift 
Keying (AFSK) of an FM transmitter the problem of 
the doppler shift is reduced. However the price to 
be paid by using FM AFSK instead of SSB is that a 
much greater signal strength is needed at the 
receiver to produce the desired reliability. 
17. to 23 @B of quieting is needed by most of the 
available Packet Radio modems to get good copy. 


Although the 6 Meter band would produce 
longer bursts and less doppler shift than 2 
Meters, most Packet Radio experimentation on VHF 
is being done on the 145 MHz band. There are also 
many more FM transceivers on 2 than on 6 Meters so 
tests were run during the 1984 Perseids meteor 
shower to prove (or disprove) that FM can be used 
as a wmode for meteor scatter Packet Radio 
communications over a path of 988 to 1208 miles on 
the Amateur 2 Meter band. 


Packet Radio stations on the east coast of 
the U.S. attempted to communicate with similarly 
equipped stations in the mid western United States 
using the following standards: 


FREQUENCY = = = = = 145.650 MHz 

E.R.P. = = = = 2 = = 1000 Watts erp (minimum) 
Transmission Sequence = Random (beacon mode) 
Transmission Mode + = = FM AFSK 

Suggested Packet mode parameters for TAPRs 
boards are listed below. 


Vdbune 
eget Set ea? Meat Sort 


MTO and/or MFROM were set to ALL (This 
allowed you to see all Packet Radio activity on 
the channel). 


For partcipating in the transmit phase of the 
2 Meter Packet Radio meteor shower test additional 
setup recommendations were: 


Set BTEXT to a brief message with at least 
your grid locator. See article in Jan 1983 QsT 
page 58 for how to determine your grid locator. 


Set UNPROTO to your state abbreviation so 
even if you go to the CONV mode and only a 
carriage return is typed, the result will be seen 
as your callsign plus state. Other TAPR boards 
would see transmissions of a carriage return sent 
by this station as K1HTV>MD, because I would have 
set the TO address field with the UNPROTO command 
to the abbreviation of my location which is MD. 


Set BEACON to BEACON EVERY 1 


Set XMITOK to ON (If a TAPR board is set up 
in this manner, the beacon text will be sent once 
every 18 seconds.) 


If beacon mesaages are being copied success- 
fully via meteor ionization and one wished to try 
to make a connect with the station heard it was 
further suggested that the TAPR board FRAC command 
be set to 1 (one second). Next, set the RETRY 
command to @ (infinite retry) which means that the 
board will keep trying to connect every FRAC time 
to the station who’s call is in the CONNECT 
command. It was recommended that if a CONNECT is 
not made within 18 to 15 minutes, that the 
stations either revert back to the BEACON mode or 
move off the 145.058 MHz calling frequency. 


Stations that wished to run meteor scatter 
schedules with other 2 Meter Packet Radio stations 
were asked to QSY to another frequency AWAY from 
the proposed M/S Packet CALLING frequency of 
145.050 MHz. 


If participating stations had the capability 
of capturing data On disk from their Packet boards 
it was suggested that they do so at all times 
while Listening on 145.850 MHz, especially during 
the hours when no one is in the shack. 


For those not familiar with the Perseids 
meteor shower, it peaked this year on August llth. 
It generally produces meteors at least 4 days 
before and after the peak day. During the peak of 
the shower as many as 60 meteors per hour are not 
uncommon. 


Ralph Wallio, WORPK, of the Central Iowa 
Technical Society also performed the same test on 
the 6-meter band at 508.585 Mhz using the same 
procedure(s}) as described above. He starteg 
transmitting at 2045 CDST on August 2, 1984 fron 
Indianola, IA. Over a 9-1/2 hour period, Bob 
Carpenter, W30TC, in Rockville, MD, received 75 
beacon packets out of approximately 3588 
transmitted (roughly 2%). WORPK was running 265 
into a S-element beam, and W30TC was receiving 
with a 6-element yagi and preamp. 


Also in Maryland, KIHTV and W3IWI were each 
sending beacon packets every 18 seconds on 
(continued on page 9) 
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(continued from page 8) 

145.05 Mhz PM {using BEACON EVERY 1 on TAPR 
boards) all through the night of August 3, 1984. 
At about 07:00 UT, the following came through at 
W3IWI, showing that they weren't alone: 


WORPK> BEACON: METSCAT IA EN31 


fom Clark saw it come through and began to 
send connect packets every 2 seconds (using FRACK 
2) to Ralph. Later in the morning, the following 
came thru again: 


WORPK> BEACON: METSCAT IA EN31 


K1HTV reports receiving a connect packet from 
WORPK and WORPK received one of W3IWI's connect 
packets. 


The following is a text of transmissions 
which were part of what is believed to be the 
first two way Packet Radio meteor scatter contact 
by Radio Amateurs utilizing the 2 Meter Amateur 
band. The contact was made by Ralph Wallio, WORPK 
in Indianola, Iowa and Rich Z@wirko, KIHTV in Glenn 
Dale, Maryland during the peak of the Perseids 
meteor shower on August 12, 1984. 


The packet transmissions of WORPK, received 
by KLHTV were captured and saved on a disk file. 
Both Stations were using TAPR terminal node 
controllers (TNCs) and operation was in the 
unconnected mode. Using the TAPR's UNPROTO 
command, either a call sign or a signal report was 
put in the TO addreas field of each packet. With 
the TNCs in the conversation (CONVERS) mode, a 
series of carriage returns (using the repeat key) 
produced a barrage of packets sent at the rate of 
over five packets per second. Thirty second 
transmission sequences were used with the 
westernmost station transmitting the first half of 
each minute. Both stations used Prequency 
Modulated AFSK. 


{Transmissions began at 93:86 UTC with 
signals being printed by KIHTV within the first 15 
minutes.) 


omd :WORPK>KLHTV: 
WORPK>KLHTV: 
WORPK>KLHTV: 


(In the first 53 minutes of the schedule 
eight bursts were heard, lasting anywhere from a 
fraction of a second to about six seconds. None of 
them produced copiable data. Then at 93:54 UTC an 
overdense meteor ionization produced a long burst 
of 23 packets of S6 reports. Signals from WORPK 
during this burst were strong enough for packet 
reception for only four seconds of the 12. second 
long burst. It Looked like this. 


emd : WORPK>S6: 

WORPK?S6: 

WORPK>S6: 

WORPK>S6:. 

WORPK>S6: 
etc. 


(23 of these packets were received in this 
one transmission. KIHTV then began transmitting 
reports of SSRRR to WORPK. In the next 96 minutes, 
between 94:98 and 05:30 UTC, eleven bursts were 
heard but no data was copied. Then at 95:45 UTC a 
single packet containing the “Rogers” was copied.) 


omd :WORPK>S1RRR: 


And with this transmission the first two way 
Meteor Scatter Packet Radio contact on the 2 Meter 
Amateur band was completed. 


During the 2 hour and 45 minute period of 
time that it took to make the 2 way packet QSO, 
activity was monitored on 3818 KHz, the primary 
frequency used to arrange meteor scatter 


schedules. Numerous 2 Meter M/S QSOs were reported 
being made on SSB in the range of 889 to 1200 
miles. The majority of theme were completed in 
less than a half hour. It is not surprising that 
it took so much longer to complete the packet QSO. 
Although the data transmission rate of the packet 
radio transmissions was about 8 times as fast as 
the SSB rate, the signal to noise ratio needed 
for FM AFSK wasn't often realized on the meteor 
bursts encountered. The duration of meteor bursts 
vary as the reciprocal of the square of the 
frequency (T°1/F°2), and the received signal 
strength of meteor bursts vary as the reciprocal 
of the cube of the frequency (S=1/F*3). It ise very 
apparent that the 58 MHz or 29 MHz amateur bands 
would be a much better choice for any future 
Amateur Radio packet meteor scatter system. There 
are a number of other modulation schemes which 
could be used to improve signal reception. 


This whole exercise of attempting to make the 
first meteor scatter packet radio QSO was done, as 
has been done many times in our hobby, to prove 
that it COULD be done. Now let us get on with the 
experimentation on improving the WAY that it is 
done, with better hardware and software. 


Kekk KKK 


The following is a circuit that shows the 
CONNECT status of your TNC on remote LEDs. The 
parts needed are a 74145, two TRI-COLORED LEDs, 
four 336 ohm resistors, (kit only, 25 pin female 
plug). Optional: red LED & resistor for FRMR 
conditon, piezo electric beeper, switch, 1.8K 
resistor, and PNP switching transistor for alert 
circuit. The following shows where to connect 
wires between the parallel port on the kit or the 
6528 on the beta board (or kit), to the 74145. 


74145 kit port 6528 function 

pin pin pin 

16 23 24 +5 volts 

8 25 1 ground 

15 15 2 PAS to A input 

14 2 3 PAl to B input 

13 16 4 PA2 to C input 

12 25 1 D input to ground 


On the 74145, pull up pins 2, 3, 5, & 6 to +5 
volts thru the 338 ohm. resistors, then connect 
the two LEDs as follows; 


LED1 flat to pin 3, other to pin 2, 
LED2 flat to pin 6, other to pin 5. 


If you want a CONNECT alert circuit (pager), 
connect the base of a PNP switching transistor to 
pin 6 of the 74145 thru a 1.8K resistor. The 
emitter thru a switch to +5 volts and the 
collector to the sonalert or a simulaler beeper, 
grounding the other side of the beeper. 


How it works: The 74145 is an open collector 
BCD to 1 of 10 decoder. The TNC provides a S8CD 
encoded output from the parallel port that after 
decoding by the 74145 provides the following 
atates: 


Pin 2 active low = DISCONNECTED 

Pin 3 active low = CONNECT attempt in progress 
Pin 4 active low = PRMR condition 

Pin 5 active low = DISCONNECT in progress 

Pin 6 active low = CONNECTED 


LED] is red on DISCONNECTED, green on CONN in 
progress. LED2 is green on CONNECTED, red on DISC 
in progress. 


Comments or querys can be made to: Phil 
Allbright, KDOEB, 3852 Neosho Ave. St. Louis, MO, 
63116 (an S.A.S.E. would be appreciated). 
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23CM Bandplanning In C.A. 


by Harold Price, NK6K 


Southern California has one of nation's 
largest densities of 144, 228, and 448 MHz 
transmitters. The southern California 
metropolitan area of 208 miles north-south by 50 
miles east-west contains 18 million people. There 
are more than 58 mountain peaks in use by 
amateurs, ranging from a few hundred to 10,000 
feet above sea level. There are hundreds of 144 
and 228 machines and more than 308 448 MHz devices 
on various peaks. Some of these are “closed” 
machines which are not listed in the various 
repeater directories. There are five crossband 
ATV repeaters, with inputs on 78cm and outputs on 
23cm, There are long waiting lists for 
coordination on all bands. “This band closed, 
Please move up" signs are posted. 


Into this fray comes a new mode, digital 
communications. The 23cm band (1240 - 1300 MHz) 
is the lowest band with room for wideband data 
(1.5 Mb, 3 MHz) in our area. On August 25, 1984, 
a Meeting sponsored by the local frequency 
coordinating group (SCRRBA) was held to discuss 
the 23cm band. An ad hoc committee of NK6K, 
WAGIPR, WBGYMH, and WB6OHHV attended the meeting to 
present the digital mede's point of view. The 
following paper was prepared for distribution at 
that meeting. A band plan was agreed on and will 
be in place in southern California for the next 
three year, at which time another band planning 
Meeting will be held. 


High Speed Digital Communications in the 
Amateur Radio Service With Special Attention to 
Activity in Southern California On the Occasion of 
the 23cm Band Planning meeting August 25, 1984 or 
“Who are these guys, anyway?" 


Summary 


Digital Communications in the Amateur Radio 
Service, of which "Packet Radio” is the current 
popular incarnation, has just entered a period of 
explosive growth. In the past year, packet radio 
has grown from a small number of isolated 
experimenters to a well coordinated group of 1780 
active users nationwide. The growth rate is 
increasing as more amateurs are exposed to the 
digital mode. As has been the case in the past 
for other modes of communication, the Southern 
California area is in the forefront of continued 
experimentation and innovation in amateur digital 
communications. 


Digital mode Spectrum needs on the 23cm Band 


Medium bandwidth: These channels will be 
used for heavy local activity. Bandwidths will be 
in the 100 kHz range. The LA to SD corridor 
already is sufficently crowded to warrant this 
type of service. Equipment requiring this band- 
width is being designed in several areas of the 
country. 


High bandwidth: Used for major trunking 
between high density areas. The SF <-> LA <-> SD 
network will certainly support at least one such 
path with in 5 years. A 1.5 MHz digital channel 
has been tested in the Bay area. Bandwidths 
nearing 1 MHz have been used experimentally in 
LA. A duplex pair using several point to point 
digital relays is a likely eventual goal. 


We see a need for a full duplex 6 MHz channel 
pair. This will consist of several channels of 
varying width as technology and load conditions 
dictate. This will allow room for “production” 
networks, links, and gateways, as well as room for 
experimentation and future expansion. 


Since the exact data rates and bandwidths to 
be used have not yet been standardized, it would 
be disadvantageous to attempt to set aside digital 
“channels® at this time. Instead, a block of 
spectrum should be set aside for “digital 
communications", with exact bandwidths and 
spacings within the block to be left to the 
regional digital coordinating group. Frequency is 
just aio small part of the total coordination 
problem for digital channels, with signaling 
rates, protocols, data modulation, network 
addressing, and other parameters all playing a 
part in adjacent channel and shared channel 
assignments. An initial unchannelized approach 
will lead to more effective use of the frequency 
blocks set aside for digital use. 


Background 


Prior to 1986, digital transmissions on the 
amateur radio bands were primarily limited to 
“RTTY", or more correctly, Baudot transmissions. 
Growth in this mode has remained steady through 
the years, with a recent spurt caused by the 
ubiquitous microcomputer. Because Baudot trans- 
missions are limited by convention, equipment, 
and the FCC to low signaling rates, the bandwidth 
requirements are proportionally low, fitting 
nicely into even the DC bands. 


After 1986, when the FCC permitted the ASCII 
computer code on the amateur bands, the fuse was 
lit. A digital boom was soon to follow. The 
reasons were simple. First, most computers speak 
ASCII as a native tongue. ASCII allows 128 
different characters, Baudot less than 68. ASCII 
could be sent much faster, by law 16 times faster 
on 144 MHz, and 256 times as fast above 420 MHz. 


At these speeds, and with the greater level 
of flexibility offered by a larger character set, 
something called “overhead” became more palatable. 
Overhead, extra characters sent in addition to 
the actual conversation or message, allows several 
things to occur. First, it provides for 
"correctness". Information corrupted by static, 
multipathing, fades, interference, or acts of God 
could be detected and either corrected or simply 
retransmitted. Second, it provided the capability 
of networking, or automatic message routing. 


To enable networking, the information being 
sent is broken down into small parts. Each part 
has some overhead added, the call sign of the 
station sending the message, the call sign of the 
station receiving the message, anda list of 
stations which will repeat the message, passing 
it through the network. 


Finally, breaking the message into small 
parts allows near simultaneous sharing of a single 
frequency by several stations, each carrying on 
conversations with different stations in different 
parts of the network. Each individual station 
would see no interference, as if he and the party 
he was speaking with were the only users. 


This can be likened to an inter-state network 
of linked voice remote bases/repeaters. Twenty 
or more users would be carrying on conversations 
traversing the entire length of the network, 
accessing the network through different or the 
same mountains, with the network automatically 
switching links on and off; sentence by sentence, 
correctly routing each word to the correct party. 
Each user thinks he has sole use of the net, and 
each voice is as clear as if it were coming off a 
compact-disk digital audio player. 

(continued on page jj ) 
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The above scenario compares to SSB on 26 
meters in the same manner as current amateur 
digital techniques compares to traditional RTTyY. 


Packet Radio, a form of digital communica- 
tions, came to Southern California in 1982. It 
was experimental, based on work done in San 
Francisco and earlier work in Vancouver, Canada. 
By the end of 1982, there were six active users 
of packet radio in Southern California, four in 
LA and two in San Diego. In 1983, Packet Radio 
took a quantum leap. From a nationwide base of 
less than 188 active users, packet jumped to 368 
users, 30 in Southern California. By August of 
1984, packet had grown to 189 users here, and 
1786 in the US and Canada, with small but growing 
enclaves in 14 other countries. Each of these 
users has compatable digital communications equip- 
ment, enabling data exchange between incompatible 
computers. More than 85% of these hams built 
their own packet radio “controller", either from 
their own design or from a bare PC board and a 
large kit of parts. Preassembled “Plug the AC 
cord in the wall" equipment has only just arrived 
on the scene. 


Packet growth shows no signs of slowing down 
and is continuing to grow at an increasing rate. 
What does this mean in terms of spectrum 
utilization by the digital mode in the near 
future? In 1982, the FCC again raised the digital 
speed limit. Bandwidths are given now instead of 
just signaling rates. The bandwidth on 70cm is 
100 kHz, above 1215 MHz bandwidth is unlimited. 


Currently, packet radio is centered on a pair 
of frequencies on the two meter band. Coordinated 
as a digital communications pair by TASMA in the 
late 1970s, 145.36/144.76 currently supports the 
bulk of packet activity. Arranged as two parallel 
paths for experimentation and load sharing, the 
pair supports seven digital repeaters, a mailbox 
system and two CP/M computer systems. Usage 
statistics kept by the computers show more than 43 
users active on a weekly basis in the LA and SD 
areas. Other groups in Santa Barbara and Twenty- 
nine Palms will soon be linked into the network. 


In a continuing experiment, a full duplex RF 
repeater is in use on 146.745/146.145. This pair 
supports a mailbox facility and an additional set 
of users. 


The initial experiments on two meters has 
shown us that although theoretically possible, 
1090 users can not effectively share a 15 kHz 
channel. Studies have shown that the maximum data 
throughput of ai shared channel is 18% of an 
unshared channel. We have also seen peak demands 
on our prototype network of four concurrent users 
running at 126 characters/sec. Using the figures 
of 486 characters/second divided by 18%, the LA 
to SD path requires a data rate of 26kB. Thus, 
we could fill a 58 KHz channel with data, not 
counting guard apace on either side, tomorrow. 


In the near future, these narrow bandwidth 
channels will serve as feeders, moving data from 
sparsely populated areas to high density gateway 
areas. An additional channel on 441.5 MHz has 
been coordinated for this purpose as well. 


We are solving the congestion problem now by 
operating less, not something a ham picks as 
first choice. Activity will continue to grow, 
As more high speed linking occurs in our area and 
between our area and others, multiple channels 
will be required. Another expanding force on 
bandwidth will be new technologies. Just as the 
current activity could be envisioned but not 
implemented using RTTY, new digital applications 
are almost attainable but out of reach with 
current data rates. Multiple concurrent digital 
voice and data streams require wider bandwidth. 
Wideband experiments are already being performed 
in various areas of the world, 9680 baud in 


Ottawa and St. Louis, 56 kb in Plorida, 166 kb in 
Sweden and soon in New England, 1 Mb in LA, 1.5 Mb 
in the Bay area. 


Room to experiment and room to grow are 
eguired to help expand the newest amateur radio 
mode. A nationwide voice network of the type used 
in the example above, implemented on a digital 
network, might not be that far off. Who would 
have believed, 20 years ago, what hams are doing 
now? Hand-held color TV linked thru a repeater, 
data at 120 characters a second from LA to New 
Zealand thru an amateur satellite 22,000 miles 
high, hand held 78cm chats between LA and Texas. 


“Ok Pred, the mouse beamed over in one piece 
but he's not breathing, crank up the power and 
try your mother-in-law". 


KAKKKKK 


Gary Kaatz, WTO looked over Lyle's article 
on link rate capabilities and reported Link 
operation at 9602 baud with his Beta TNC. 


The Beta TNC does not have a high speed clock 
option and is limited to 4800 baud. In order to 
get the x32 clock for the WD1933, I divided the 
6551 baud rate clock of 1.8432 MHz by six in a 
74LS92 to provide 307.2 KHz to the  wbdl933 
(32*9600). I tested using 9680 baud for the 
terminal rate and used a digital loopback, to 
allow connecting and digipeating through myself. 


There was no problem in sending short packets 
with up to eight digipeaters as long as I waited 
for the packet to be ACKed. This was not the case 
when the link was overloaded. If I used only 
three digipeaters and sent a long packet (249 
characters), the TNC sent it once then stopped. 
Sometimes after things appeared to have stopped, 
hitting another carriage return would induce the 
previous packet to continue. Other times the TNC 
would just not ever transmit again, requiring a 
software reset to recover {RESET command). With 
seven digipeaters, 1 could even cause the TNC to 
“go off into the woods” by rapidly sending several 
One character packets before the first was ACKed. 
Once, the TNC erased the NOVRAM during this test. 
Even at a link rate of 1200 baud, I observed the 
tendency to stop transmitting. 


I then borrowed a kit TNC in order to monitor 
the activity using TRACE (I used the high speed 
clock option and found that it worked just as Lyle 
reported). There were a lot of extraneous packets 
flying around, no wonder the TNC became over- 
loaded. Even after a packet was received, but 
before the ACK filtered back, it might be sent 
several more times so the receiver was sending 
back many REJ ACKs. Even with a noiseless digital 
channel (a wire) sometimes the packet was not 
received correctly and had to retry. 


I then connected the two TNCs so that they 
could communicate with each other by connecting 
the TXD of one WD1933 to the RXD of the other. 
With no digipeaters I could even send a long file, 
loading it into the kit TNC at a rate of 9600 baud 
and watching it at a rate of 380 baud on the Beta 
TNC. Using two digipeaters, the Beta TNC would 
eventually crash. The other way around (including 
the terminal rates), even with no digipeaters, the 
Beta TNC would lock up and would not transmit as 
reported above. Even though it would not 
transmit, it would still receive, but not ACK. 


I then operated the kit TNC at the normal 
clock rate and generated the x32 clock for the 
WD1933 the same way I did for the Beta TNC. Now, 
when sending a file, more often than not one or 
the other TNC would either stop transmitting or 
“go off into the woods” even with no digipeaters. 
I can therefore only concludethat the standard TNC 
will not support 9680 baud links except by waiting 
for each packet to clear the link. 
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TAPR’s Future 


by Harold Price, NK6K 


The following was placed on CompuServe in 
reply to the questions “What is TAPR doing about 
level three?" and “How far in the future do you 
see TAPR selling TNC kits now that there is a 
commercial interest in the game?” 


The following views are mine alone, and do 
not necessarily refect those of TAPR, AMSAT, VITA, 
LAPS the staff management or janitorial depts. 


The TAPR folks are indeed up to something. 
We now have the TAPR Pascal code running happily 
under a simulated environment again. When I left 
my previous employ to work on PACSAT I lost access 
to the development environment we had used to get 
the TNC code written. The software, with only one 
change (a shift(var,4) changed to var shi 4) runs 
under TURBO Pascal on the Pronto-16 I spoke of 
earlier. This will vastly speed up development, 
which has slowed down as of late. Margaret, KV7D 
is expecting a little packet of joy in July, so 
she will be home bound during July and August. 
Look for great things before September. 


The plan is to come up with version 4.0 of 
the TAPR TNC software which will allow testing of 
both datagram and virtual connection protocols. 
As I said in a message to Norm, I think the level 
two wars are over. With 1388 TNCs in the field 
from 6 “manufactuers" all running the same level 
two, anyone proposing a switch now is just rocking 


the boat. The few proposals I've seen for 
different level twos offer no concrete advantages 
over what we've got now anyway. Besides, level 


two is boring (now that we have one that works), 
the real fun is level three. 


There is currently a necessary kludge in 
AX.25 called digipeating which is a very demented 
level three feature. Digipeating allows two TNCs 
to be connected using a third as a relay. Without 
this simple addition to AX.25, packet may not have 
taken off as it did, since digipeating allows many 
more users to reach each other. 


TAPR took this benign dementia a step further 
by allowing multi-hop digipeating, ie. the two end 
points were connected by an ordered list of digi- 
peaters. We picked an infinite number (8) as the 
total number of hops. My feeling is that the 
chances of a packet makine 8 hops without getting 
trashed and then the ACK coming back thru 8 hops 
without getting trashed is close to zero. 


After much kicking and screaming on the part 
of some vendors, everyone has pretty much followed 
suit since there are areas of the country where 
the packeteers are not lucky enuff to include in 
their number someone with his own repeater channel 
and a set of users who are willing to cease voice 
operation. If you haven't got a wide coverage 
duplex repeater (or even if you have), digipeating 
is our best bet for now. 


Anyway, level two is point to point, with 
level two+t in current style, multihop dumb 
repeating. The + in level two will die a happy 
death when we get level three up and running. 
Level three links two end points thru multiple 
intermediate TNCs. The linking is done in an 
intelligent manner. ACKing is node to node rather 
than end to end. In level two digipeating, each 
intermediate point simply regenerates the packet. 
It does not ACK it. The final end point ACKs it, 
and the ACK is blindly repeated back to the 
starting point. If any repeat of the packet, or 
the ACK, is stepped on or dropped, the packet must 
start over from the beginning. 


In level three, an ACK can occur at each step 
of the way. Thus, a packet may only have to be 
re-sent between relay points five and six, rather 
than starting again at point one. So why don't we 
get on with it, you might ask? 


There are many problems involved. Flow 
control, network blocking, routing, on and on. To 
get back to the question, what is TAPR doing? 


A node in a level three network will want to 
be connected to more than one other node. 1 think 
this is the case for most of the connection 
oriented protocol options. We will allow the 
TAPR TNC to maintain multiple level two connects. 
This has several implications. First, you can 
carry on two or more concurrent conversations. 
Not so good for rag chewing maybe, but great for 
emergency communications. Imagine a TNC in the 
local disaster center. Currently you can carry on 
a conversation with only one other TNC, with 
limited possibility of a priority break-in from 
another TNC. With all outlying TNCs connected to 
the central node at the same time you get closer 
to what you want, high reliability connections 
with each of the field guys at the same time. 


Next, and even better, you can automatically 
route one connection stream to another. Here's an 
example. The following syntax is probably not 
what we'll end up with, but the idea is: 


MYCALL NK6K 
{1] CONNECT WB6YMH 

[1] CONNECTED TO WB6OYMH 
{2] CONNECT WA6GJPR 

{2} CONNECT TO WAGJPR 
rouTE [1] To [2] 


At this point, your TNC is now a network 
node. Anything that comes in from stream [1] gets 
acked at level two. The data from the packet gets 
routed to stream [2] where it gets sent out and 
saved until an ACK comes in on stream [2]. The 
versa is also true, incoming from [2] goes to [1]. 


Now, wouldn't it be great if you could cause 
the other guys board to make a connection? If I 
could tell WA6JPR to make a level two connection 
to WESEKU? And what we have is the level three 
function, endpoints linked thru multiple inter- 
mediate points. A lot of things are missing, but 
this simple mechanism allows testing of level 
three concepts without a lot of hassle on the 
userg part. We will also design an interface 
(based on asyncronous LABP) between the TNC and 
its attached computer to allow the computer full 
control over the link process. This permits the 
use of the TAPR TNC as a level two black box, with 
level three functions done in your host. 


Do I expect everyone to run verson 4? Well, 
why not? The design goals of the TAPR TNC were to 
design in one box everything needed to experiment 
with the uses of packet radio. To get past the 
issue of level two, and on to applications of 
packet, and higher level protocols. I think that 
we have met this goal. The TAPR TNC is now in use 
in many counties, 25S, ZL, VK. JA, PY, PA, ON, DL. 
It is in use on many modes, HF SSB at 300 baud, 
Oscar 18 SSB at 12608 baud, OSCAR 16 PSK at 400 
baud, VHF FM PSK at 4868 baud (bell 208 modems), 
as well as standard VHF FM 1208 baud FSK. On the 
other hand, version 3.1 can still be used point to 
point, and thru 4.0 gateways get full access to 
network. But just as everyone having the 
capability of being a digipeater added to the 

(continued on page 13) 
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swift growth of packet in spread out or low 
density areas, so will the ability for anyone to 
be a level three node speed growth in that area. 


But I ramble. The other attribute of a net- 
work node is the ability to connect to more than 
One RF path at the same time. Lets assume a 120608 
baud link on 2 meters and a 2488 baud link on 228, 
feeding a 9668 baud link on 448. Basically. the 
hardware arm of TAPR is designing a fancy multi- 
port hardware controller. Several designs have 
been proposed, one is motherboard with slots for 
Plugging in a number of channel controller cards. 
Each channel control card is a mini TNC, handling 
all channel access and level two functions. The 
mother board passes data between channels as well 
as handling level three and higher functions. 


We don't expect everyone to have one of 
these, which are called TNC-LINKs, by the way 
(pronounced tink link). But they will make great 
mountain top controllers, especially when used 
with the PACSAT 9600 whiz bang modem. 


To answer your final question, how long do I 
see TAPR building kits. There are two answers, “As 
long as there is a demand" or “Until we can’t 
stand the sight of them anymore". Since I'm not 
located in the teaming hub of Tucson, but am 
instead located in the outlaying area called LA, I 
haven’: been pressed into the chain gang of kit 
packaging, but isn't much fun. Especially when 
serial number 1000 has long since gone out the 
door. The kits are TAPRs only source of income. 
And when we say we are selling them at cost, we 
aren't kidding. An extremely small amount of each 
$248.88 goes into our fund for future development, 
Il‘ve forgotten exactly how much. Remember, no one 
is on a salary at TAPR. A number that does come 
to mind is the cost of the cabinet kit. Your 
cost, $69.88, our cost, $67.68. Our original 
goal was to make packet available to a large 
number of people at reasonable cost, delivering as 
full ai function device as we could. It is 
possible to deliver less function for less cost. 
It is possible to deliver the same function 
assembled, tested, and warrented, for a larger 
cost, There are several market niches out there, 
and we will continue to ship as long as 1) there 
is a niche for us and 2) we're having a good time. 


The Tucson folks tell me that they have 
gotten some phone calls in the last few days 
saying they saw a message on HAMNET that TAPR 
wouldn't be making kits anymore now that AEA was 
making the PKT-1. I don't remember seeing that, 
but here is a message saying it ain't so. We'll 
keep cranking them out, with the above mentioned 
caveats. Is the PKT-l worth the additional cost? 


It depends on how you value your time. Take 
the kit, $248, and the cabinet, $708.82. Total 
cost $310.08. You're looking at about 11 hours 
contruction time. If you consult for as little as 
$17.@6/hr, in those 11 hours you've made up the 
difference. Like to buy the component and get on 
with higher function experimentation? Want the 
security offered by a reputable commercial dealer? 
Spend the money. Like to build? Buy the kit. 


Only got $158.88 but want to get on packet? 
Interested in local two meter FM work, or want to 
run a low cost remote digipeater? Buy the GLB. 
Got only $150.88 but want to run 300 baud HF, 
escar 18 with on board filtering, or experiment 
with 4880 baud? Want a 248 page manual/tutorial 
On packet radio? Save up some more money. 


Want to do all of the above and like to roll 
your own? Did you get in on the $58.08 Xerox 82d 
board blow out? Keep your eyes down south, a 
group in Florida is brewing a board that plugs 
into the PIO chip socket that adds dual channel 
HDLC hardware. Expect to see the TAPR code ported 
to that hardware configuration soon as well. 


These quickey comparisions are vastly 
simplified, of course. Each of the TNCs has its 
own niche. As always, think about what your needs 
are, then spend as little as you can to get it. 


Are we having fun yet? You bet! 


A for-profit company would be crazy to 
discuss future products like this before the 
product is ready to ship. But we’re a non-profit 
R&D company, trying to make packet the mode of the 
future. Just remember, you saw it here first. 


KKKKKKK 


Tucson Amateur Packet Radio (TAPR), an inter- 
national Amateur packet radio research and 
development group based in Tucson, Arizona, is 
proud to announce the opening of its office, 
effective Monday, August 28, 1984! 


The office address is: 
Tucson Amateur Packet Radio 
1016 East Pennsylvania Avenue 
Suite 382 
Tucson, AZ 85714 


The mailing address remains: 
Tucson Amateur Packet Radio 
P.O. Box 22888 
Tucson AZ 88734-2888 


The telephone number is: (602)-746-1166 


The office hours are: 9:00 AM - 5:38 PM 
(Mountain Standard Time) Monday through Friday. 


The gentle voice at the TAPR end of the 
line belongs to Karen Makus. Karen is a non- 
technical person, s0 please don't ask her how to 
write a terminal program for your packet stationlI 
However, in her role as Office Manager, she will 
do everything she can to expedite servicing your 
information requests, providing spare parts 
support for your TAPR TNC, filling orders, etc. 


Technical questions will be routed to 
volunteer staff for answering, so please mail such 
questions to the TAPR P. 0. Box. 


It is our goal to provide 48 hour (or faster) 
turnaround on all standard transactions (member- 
ships, renewals, TNC and parts requests, general 
information needs, etc.) and faster service on 
non-standard ones. We at TAPR wish to thank you 
for your continued support, and look forward to 
being of greater service to you. 


On October” 7, 1984, a group of Nebraska 
amateurs formed the Cornhusker Amateur Packet 
Radio Association (CAPRA). The next meeting will 
be at 1388 CST on January 6, 1985 at the hone of 
Lyman Nelson, WBOIEN, in Hooper, NE. 


Hank Magnuski, KA6M, has had his new 9600 BPS 
switched network analogue MODEM product reviewed 
in the July issue of Byte magazine, Page 354. 
Hank is the proprieter of Gamma Technology in Palo 
Alto, CA when he isn’t working on packet. 


The new product is an intelligent MODEM built 
On an IBM PC card that hustles along at 9600 BPS. 
This is no mean trick over the telephone network 
and is a significant breakthrough in telecommuni- 
cations capability for the Pc. If you're moving 
much data around the country on the switched net- 
work, especially in the middle of the night, this 
preduct should prove in on a very short psy back 
pericd and find a large and growing market. 
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PACtivities 


On 6/1/84, the Board of Directors of TSARC, 
the Tri-State Amateur Repeater Council, meeting in 
Executive session, took the unprecedented step of 
reversing its original position on the ccordina- 
tion of non-traditional modes such as packet 
radio, RBBS and MSO systems and simplex auto- 
patches. TSARC had originally decided that such 
operations, because of their simplex, single- 
emitter concepts, did not really relate to the 
coordination philosophy already in place for 
repeaters using the classic two-channel input/ 
output frequency structures and principles, and 
that consideration of requests for coordination 
would have been inappropriate. 


After much discussion and deliberation, the 
Board voted to give full consideration to the 
coordination of such simplex operations as packet 
radio, radio bulletin board systems (RBBS), 
message storage operations (MSOs), mailbox 
systems, and Legitimate simplex autopatches, and 
resolved to: 


(1) Establish the concept of the coordination 
of certain specific VHF and UHF channels based on 
the mode of operation, as well as geographical 
area and physical separation considerations; 


(2) Reeognize, acknowledge and support the 
use of the frequency 145.018 as a de facto East 
Coast standard, and to formally recommend that 
145.018 be reserved for exclusive use by stations 
operating packet radio systems; 


(3) Recognize the requirements for a special 
wide-band channel coordination and allocation in 
the 220 MHz band, and establish and coordinate a 
single 100-KHz wide channel from 228.500 to 
228.600 MHz for exclusive use by packet radio 
systems, pessibly for 56 kbit/s packet radio trunk 
and backbone services. 


This last item was given exceptional urgent 
emphasis and attention in view of the recent 
public statements by Robert Foosaner, Chief of the 
FCC's Private Radio Branch. In his speech at the 
FCC Forum at the recent ARRL National Convention 
in New York City, Mr. Foosaner clearly outlined 
the need for allocations of additional new 
channels in the Land Mobile Service, and that the 
Commission would be looking at all parts of the 
spectrum for suitable frequencies, including the 
possible re-assignment of some portions of the 
amateur radio band at 22@ MHz. The Board noted 
that certain commercial interests had already 
filed formal petitions asking specifically that 
the Commission re-assign the frequencies 216 to 
222 MHz to the Land Mobile Service. 


It was the Board's very strong feeling that 
the coordination of the 188-KHz channel 226.580 to 
228.680 MHZ would conform to the requests and 
needs of amateur operators working in the most 
sophisticated technologies, and clearly demone 
atrate to the Commission that the Amateur 
Service’s most advanced technologies were finding 
a home in the lower portion of the 22@ MHz band, 
establishing maximum visibility and credibility, 
something that has not been noteworthy on 220. 


The Board also established a requirement for 
the re-evaluation, and revision of existing TSARC 
recommended technical operating standards, 
including immediate efforts to study and 
incorporate new technical operating information 
appropriate to the packet radio, RBBS/MSO and 
other non-voice operating modes. TSARC welcomes 
and encourages input, comment and suggestions from 
Other coordinating councils in these matters. 
Comments of a technical nature can be mailed to: 


Norman Sternberg, W2JUP Vice-Director (516), 
TSARC Box 125, Farmingville, NY 11738 
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The AMSAT/APL packet repeater in Maryland is 
now signing the call W3VD-5 on 145.01 running 25 
watts. Reports from MD/DC users indicate very 
good coverage over a 30-50 mile radius. 


The second informal meeting of OPEC (Oahu 
Packet Radio Enthusiasts Club) met the first week 
of July. Of the known 12 Packet Stations in 
Hawaii, seven were in attendance. Eleven of the 
stations are using TAPR TNC boards. (There is one 
GLB out there!) There are at least two Packet 
Stations on the neighbor Islands. 


Several months ago the video tape of Pete 
Eaton's talk in Iowa was obtained by KH6FIC and 
has been shown to the Honolulu Amateur Radio Club 
and other groups. This has been a stimulation for 
Many to ‘get-into’' Packet Radio! How Pete managed 
to pack so much information in a one hour tape is 
amazing in itself. But then, Pete is a pretty 
amazing guy! 


The initial OPEC group is: AH6AC Dale, KH6DD 
Pat, KH6FIC Jim, KH6FMT John (on Kauai), KH6GMP 
Gary, KH6GPI Hal, KH6JEO Tony, KH6NP Bob, KH6PS 
John, WBS7SZC Jay, KH6WY Jack, and WH6AMX Rick. 
Rick is the AMSAT Coordinator for the Pacific and 
is among three others who have had Packet QSOs via 
OSCAR-10! (Blame Gary for the club name!) 


The big event at this meeting was the 
decision to install a dedicated DIGIPEATER 
(hopefully on one of the Mt. Peaks in an attempt 
to cover the entire State). Enough money was 
tossed into the Calabash Bowl that a TNC has since 
been ordered by Dale, AH6AC, who will assemble and 
test it. A 2-meter rig was offered for DIGIPEATER 
use and I am sure an antenna will make an 
appearance. In any event a gcod LAN should be up 
and running scon! 


Most, if not ali of us, use personal 
computers as terminals: and most use additional 
software rather than straight "dumb-terminal’ 
configuration. There are at least four of us who 
use 48800 baud terminal interfaces and that makes 
it all the more interesting! Several are using 
Ascii Express “Professional” and that goes quite 
nicely with the TNC. In fact, Dale, AH6AC, is 
leaving his Apple on all day as a BBS which 
permits the rest of us to upload and download 
files as well as use it as a Packet Mail-Box. 
Following the advice of Lyle Johnson and Harold 
Price in the last PSR concerning the setting of 
AWLength to 8 andPARity to 4, we can now exchange 
binary as well as text files. We expect to get a 
bit fancier BBS by the time the digipeater is up 
and running! In the meantime Dale‘’s BBS layout 
serves us quite well. 


Only one had any admitted difficulty in 
getting his board vp and running. That one was 
John, KHGFMT! He couldn't get his PTT LED to turn 
off. It was really giving him fits until he 
finally found that the DIP socket for the HEX 
Inverter (U21) had an internal short which of 
course was corrected by replacing the socket. 
(John will tell you that his faith in OHM’s law is 
now reaffirmed. But for a while he was doubtful 
about continuity checking!) 


Without exception all of us have been greatly 
impressed by the professional board layout, the 
outstanding firmware, and the great documentation 
provided. How it all got done without a lot of 
hired help and how self imposed deadlines were met 
is-a tribute to a lot of very dedicated people. 


The address for OPEC is P.O. Sox 1355, Pearl 
City, Hawaii 96762. ALOHA NUI LOA from here. 
(continued on page 15) 
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The Rocky Mountain Packet Radio Association 
(RMPRA) was organized earlier this summer. The 
membership is now 48, and with annual dues of $28 
the treasury is building nicely. When we look to 
the expense of linking hardware and related costs, 
however, we need more money. One approach we are 
using may be of interest to other packet groups. 


The largest amateur supply dealer in the 
region has agreed to put an assembled kit in 
operation at his store for demo purposes. At this 
time he does not stock any of the commercial 
packet gear. The RMPRA is supplying the TAPR TNC 
kit board for the demo. 


We expect to boost packet activity in the 
area, get good exposure for the TAPR TNC, and 
expand our membership. We will at the same time 
advertise that the kit can be had in assembled 
form for an additional $75. RMPRA members will do 
the assembly while the RMPRA treasury benefits. 


The Rocky Mountain Packet Radio Association 
(RMPRA) is now operating, what we believe to be, 
the most sophisticated bulletin board around. 


The system used is a packet modified version 
of The Bread Board System (TBBS) by Phil Becker, 
WBOEIV. The system was donated and modified 
Phil, and his distributor Dave Ebert, W7RH (Ebert 
Personal Computers, Aurora, CO). 


Don Brown, NOBRZ, is the SYSOP. He has 
supplied a TAPR TNC kit, TRS-88 Model III, radio, 
and related equipment. It operates 24 hours per 
day and is capable of monitoring several frequen- 
cies as well as standard telephone BBS operation. 
Our Pikes Peak geostationary digipeater at 14,118 
feet provides wide area access to the BBS. 


Anyone interested in sampling the system we 
are using can call the TBBS Headquarters Board at 
(383) 690-4566. Don's number for the RMPRA board 
is (303) 452-4735 (word=8, paritycnone, stop=l, 
terminal echo=on or half duplex, 308 baud for the 
time being). 


Call signs and names of packeteers in the 
D.C. area (T = TAPR TNC, V = VADCG TNC): 


KLHTV (T) Rich KAIGD (T) Andy 
KAITB (V) John WB2KDR (?) Jerry 
K3HOI (V) John KE3Z2 (T) John 
W3AUN {(T) 8ii1 W3IWI (VT) Tom 


W3oTc (T) Bob W3TMZ (T) Jack 
K3TCT (T) Bob N3DCI (Vv) Bill 
WA3MEZ (V) Rod WA3WQZ (V) Chuck 


Wacql (T) Cliff wapusy (T) Dick 
W4MIB (V) Bill WB4NFB (V) Bill 
WB4APR (V) Bob WB4JFI (V) Terry 
WBSMMB (V) Sandy WDSDBC (V) Howard 
K8MMO (V) Dave KASNWB (T) George 
AJ9X (V) Mike 


At the last meeting of the Minnesota Repeater 
Council (MRC), Rick Whiting, WOTN, agreed to 
conduct a study of, and prepare a recommendation 
for, the provision of frequencies for digital 
communications service in the frequency coordina- 
tion policies and procedures. As a result of his 
study he plans to propose at the next MRC metting 
that five 28 kHz channels beginning at 145.81 Mhz 
and ending at 145.89 Mhz be set aside for digital 
communications including digital repeaters (freg- 
vencies are channel centers). Coordination of 
specific stations on these channels is not being 
proposed. Assignment and use of said channels for 
@igital services (meaning packet radio at this 
state of the art) will preclude their use by non- 
digital stations. 


At approximately 6708 UTC on June 7th, 1984 a 
new packet station in Munich, DL3MAO, “Bernie“ 
reported copying packets from Wes, K7PYK, in 
Arizona on the Osear 18 digital channel. 


Bernie reports that there are four TAPR 
boards on the air in the Munich area, and another 
four in the Hannover area. He also has learned 
that there is now an active group in Switzerland, 
near Zurich. 


Junior, PY2BJ0O, of Sao Paulo, ia interested 
in running a test of HF packet communication using 
the phenomenon of TE (Trans-Equatorial) propaga- 
tion, since he has observed strong signals from 
the US between 2196 and 2208 UTC. He suggests the 
use of 28.7 Mhz with Pl 1280 baud 1006 Hz shift or 
29.5 Mhz with F3 Bell 282 AFSK. Junior can be 
contacted via his call book address or on the 
OSCAR 18 packet frequency of 145.832 Mhz on the 
downlink for setting a schedule. 


Following is JAISYK's report on Packet 
meetings held in JA3. He was in that area on 
business and attended. 


On the evening of June 15th I attended a 
Packet meeting at the shack of JH3BJUN. I arrived 


at his house before nine. I could meet a lot of 
stations who are interested in Packet Radio 
communications. Those present at that meeting 
ancluded; 


JA3RCT Hisamathu-san JARL Kyoto shibu-cho 
JA3IXF Ozaki-san versed in P. computer 
JR3INWZ Nakamura-san game as above 

JF3GFH Mashiba-san St. of Kyoto Uv. 
JGINTF Inoue-san study abroad in USA 
JH3UBF Minami-san came from Shiga Pre. 


We were successful in exchange of packets 
from his PC-8801 MK2 to his PC-8001+PC-8012 
using my Z2-8538 boards. I told them everything I 
have known from my experiment of Z-SCC and patched 
l/tipm. We discussed Modem, TNC, HLDC, Gateway, 
Digipeter, Mail-box and much more. 


Hisamathu-san who is JARL kyoto-shibu-cho 
said let's do the Packet Radio in Kyoto. Nakane- 
san will connect his GLB-TNC and his 72-8536 
board through the modem. He copied the patched 
1/tipm on C-DOS and P-DOS for his PC-8801 MK2. 


They returned to their home at about 3:90 AM. 
I expect that they will succeed with the Packet 
radio experiment in Kyoto area. 


Re. PCBs Of AFDEM-JA, Nakane-san told me that 
he ordered 28 PCBs from his friend for alfa-test. 


KD7UW reports that packet radio is alive and 
well in Seattle, WA on the following frequencies: 


147.608 simplex ---- main digipeater and mailbox. 
145.818 simplex ---- planned for regional Linking. 
224.658 simplex/duplex ---- planned for linking. 


We are proud to announce the arrival of two 
prospective packeteers into the ranks Of TAPR. In 
July, Dan (KV7B) and Margaret (KV7D) Morrison 
brought home a baby girl whe they named Ruth 
Ellen, and was followed in August by another girl, 
Janna Marie, born to Pat Snyder, WASTTW, and his 
wife Julia. 
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A Fuel For Thought 


by Jan King, W3GEY 


The Space Shuttle has modified the method 
by which space-bound payloads enter orbit for the 
forseeable future. The STS offers the promise 
of lower payload cost and the ability to carry 
large payloads into orbit to mention but a 
few of its primary objectives. Por very low 
cost payloads such as those pioneered the 
radio amateur community (the OSCAR series), the 
Space Shuttle poses, however, a number of severe 
engineering obstacles which have become major 
stumbling blocks to the exploitation of this 
valuable resource. Not unlike most free fiying 
satellites, the communications satellites launched 
by radio amateurs and used in the Amateur 
Satellite Service are intended to meet long life 
objectives. In addition, to meet mission 
objectives for the communications service to be 
provided either a geostationary transfer orbit or 
a sun synchronous polar orbit must be attained by 
the spacecraft. Unfortunately, neither of these 
objectives can be met by the standard provisions 
of a Space Shuttle mission. 


STS orbits, typically 296 km in altitude and 
inclined from 25 to 57 degrees are unstable. A 
small spacecraft, with a low surface area to mass 
ratio, will decay fram such an orbit in a matter 
of months. This class of orbits, with a few 
exceptions, is also unsuitable for communications 
experiments of interest to the Amateur Satellite 
Service. It is therefore a necessary requirement 
for Amateur Satellites and other free flying 
epacecraft seexing stable orbits to carry a 
propulsive capability if launched by the Space 
Shuttle. 


Having accepted the burden of a propulsive 
system as an added spacecraft complexity, yet 
another problem becomes apparent. Classical 


propulsion systems employed by satellites are 
characterized as hazardous devices. Due to the 
manned presence on board Shuttle safety 


considerations are necessarily more stringent 
when using this method of launching a spacecraft. 
The added complexities and paperwork resulting 
from the inclusion of hazardous devices on board 
Shuttle launched satellites conflicts with the low 
cost nature of these programs and may make such 
payloads totally impractical or viable only if 
launched by alternative methods. This problem is 
exascerbated by the fact that most orbit alterna- 
tives can be reached from Shuttle orbits only by 
multiple delta-V = maneuvers. This requires 
multiple solid rocket engines or a _ restartable 
engine on board the satellite, further multiplying 
the safety hazard problem. 


A solution is sought to the "Shuttle 
Dilemma." The Shuttle Dilemma may be defined as 
follows: 


(1) A Ghuttle payload is always two burns 
away from the desired orbital elements when 
separated from the cargo bay. 


(2) The cost of NASA safety approval for a 
propulsive device used aboard Shuttle by a low 
cost user is approximately a factor of three 
higher than the entire cost of the payload itself. 


(3) As a rule of thumb, the mass of the 
paperwork necessary for NASA approval of a 
hazardous device for a Shuttlé flight is greater 
than or equal to the mass of the payload. 


While the above may seem humorous, these 
statements are all too true and must be dealt 
with squarely by would-be Shuttle low cost payload 
designers. 


A propulsion system that would solve the 
Shuttle Dilema could be expected to have the fol- 
lowing characteristics: 


{1) The propellant used should not be a 
chemical, pressue or explosive hazard as defined 
by NASA or the USAF (ref. AFETRM-127-1). 


(2) The loading of propellant into the space- 
craft should not constitute a hazardous activity. 
No special safety equipment should be required. 


(3) No portion of the propulsion system 
should contain hazardous devices of any kind. 
Certain exceptions to this rule might be taken 
to include category B electro~explosive devices 
such as pyrotechnically operated valves. 


(4) No portion of the propulsion systen 
should be pressurized or become pressurized even 
remotely while the satellite is on the ground, 
during powered flight or during astronaut 
activities in orbit, including those conducted to 
separate the satellite from the Shuttle. 


(5S) No portion of the propulsion system 
should be susceptable to damage due to the 
environment of the Cargo Bay during powered 
flight or in orbit prior to or during separation 
of the satellite. 


The Radio Amateur Satellite Corporation 
(AMSAT), having had practical experience with 
beth liquid and solid propulsion systems on 
board low cost satellites believes that the 
above requirements will prove to be virtually 
Mandatory for low cost payloads flown by the 
Space Transportation System. Two methods have 
been considered for some time by AMSAT that appear 
to meet the above five conditions and produce 
satisfactory performance for space applications. 
Both involve using water ag a fuel and both have 
been considered by other groups from time to time 
as methods of space propuision. 


PROPULSION VIA WATER ELECTROLYSIS: 


The propulsion of a space vehicle via 
hydrogen/oxygen fuel produced from the electroly- 
sis of water is far from a novel idea. Hughes 
Aircraft Company, Space Systems Division 
documented the results of an internal research 
and development IR&D project which developed 
a working model of a water electrolysis rocket 
during the first half of 1964 (1,2,3,4). Using 
this technique a single pressure vessle acts as 
storage for the water and electolyte, as an 
electrolysis chamber and finally as a pressure 
bottle for the combined electolyzed gasea. The 
premixed gas may be fed via a single line into 
the injection chamber of a small rocket engine 
or thruster. In their final report on this 
technology Hughes stated, “The Water Electrolysis 
Rocket has been explored in sufficient depth to 
verify the feasibility of the concept. Further- 
more, it has been determined that this system 
offers significant advantages over other 
presently available reaction control systems. 
Among these advantages are: 


1) Higher specific impulse 

2) Lower system weight 

3) Lower power requirements 
4) Extended life in space 

5) Improved system reliablity 
6) System simplicity 


(continued on page 17) 
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It is interesting to note that at the time 
of the writing Hughes did not cosider the safety 
advantages of the system which are of prime 
interest to AMSAT. The specific impulse of 
a small electrolysis motor of the type required 
for a low cost satellite mission is between 330 
and 362 sec. This is considerably better than 
either an equivalent solid or bipropellant liquid 
motor system (276 and 385 sec. respectively). 
Preliminary investigations by AMSAT suggest 
that the power required to electolyze one 
kilogram of water is approximately 5,089 WH. 


It is not known why Hughes did not continue 
to develop this technology to the point of 
commercial introduction. Clearly, however, mono- 
propellant hydrazine systems replaced other 
methods for reaction control starting about the 
same time as the Hughes research on water elec- 
trolysis motors. Since this work was done there 
have been dramatic improvements in both elec- 
trolysis electrode and thruster technologies. 
AMSAT has also conducted preliminary studies on 
an advanced method of drying the hydrogen and 
oxygen gas which should lead to improved thruster 
performance. This was one problem reported by the 
Hughes research team. 


PROPULSION BY STEAM EXPULSION: 


A second method of exploiting water as a 
safe propellant is by means of a small steam 
engine integral to the thruster in a water fed 
propulsion system. Water is allowed to superheat 
in a small chamber adjacent to an expansion 
nozzle. Thrust is produced by the acceleration of 
water molecules as they exit the nozzle. The 
specific impulse of this technique is far poorer 
than the electrolysis method (1087 sec.}, however, 
the system complexity is very low indeed and the 
energy required to liberate a kilogram of water 
into eteam is only 758 WH, considerably less 
than with electrolysis. The specific impulse for a 
motor of this type can be shown to be governed by 
the equation: 


Isp = SORT 


}2ckK Tb (1 - spexttsbonenuseecensseal 


i Te = Tin m ] 
where: 
c = Heat capacity of propellant 


(water = 1.3) 


K = Boltzman Constant 
(1,.386-23 J/K) 


Tp © Gas Temperature 
(approximately 489K) 


n = molecular weight of propellant 
(water = 18) 


m = mass of a hydorgen atom 
(1.66E-27 Kg) 


Poxit = Nozzle exit plane pressure 


(assumed = 9.91 Bar) 


P . = Thruster chamber pressure 
oon (assumed = 5.8 Ba) 


As can be seen, the specific impulse 
depends inversely on the molecular weight of the 
fuel used, taken to the 1/2 power. This favors 
the use of low molecular weight fuels. As can 
be seen water is nearly optimum for an engine of 
this type particularly when the other physical 
properties of this fluid are taken into consid- 
eration in a practical system. 


While, on balance, a system using steam as a 
propulsion technique is far from optimum with 
respect to Isp it is simple enough to be included 
on even GAS CAN mission and can solve a 
reasonable number of propulsion problems for 
gmall spacecraft. Figure 1 reviews the perfor- 
mance of this system for a variety of missions of 
interest to AMSAT and gives a comparison to the 
electrolysis method. 


ORBIT CORRECTION TECHHIQUE 
USI5EG WATER PROPUSLION METHODS: 


A salient characteristic of both prepulsion 
techniques reviewed ia that they take electrical 
energy from the solar arrays of the spacecraft 
and convery it into potential energy (either in 
the form of stored gas to be burned or in the form 
of stored electrical energy). Thrust is bast 
produced ina burst mode rather than with a 
continuous firing. This is a typical operating 
mode for a reaction control system (RCS) but 
is somewhat unusual for an orbit transfer 
maneuver. In effect, time is traded against the 
burn duration (power production rate of the 
satellite) so that a reasonable compromise for 
the total duration of the propulsion phase of 
the mission is reached. An important consider- 
ation for auch a mode of operation is that the 
total delta-v achieved per day during the 
Maneuver must be greater than the deceleration 
per day due to drag in the Shuttle base orbit. 
The orbit transfer strategy for circular orbits 
with a spinning spacecraft is shown in Figure 2. 
Two small thrusters at either end of the satellite 
are employed. Firings always occur at the line of 
apsidies. Alternate thrusters are used so that a 
first firing occurs at perigee thus raising apogee 
and a subsequent firing occurs at apogee now 
raising perigee. Mini-Hohman transfer maneuvers 
are repeated until the desired circular altitude 
is reached. Eliptical orbits can be achieved with 
a single thruster fired at consecutive perigees 
thus continuously raising apogee. Inclination 
changes with this technique are also possible and 
are most efficiently applied when apogee also 
coincides with the ascending node of the orbit. 


The techniques reviewed have been considered 
in the past by space research projects and by 
commercial spacecraft manufacturers. While these 
propulsion technologies have never been reduced 
to commercial practice, sufficient study has been 
done to verify their applicabiity to space 
missions. If the STS is going to fulfill its 
mission as a launcher for ALL space interests 
then some acceptable methods of propulsion must be 
found for smaller payloads. These methods must 
take into consideration the low cost nature of 
such projects and the very stringent safety 
constraints imposed by NASA on all STS users. In 
view of the above AMSAT believes that water 
propulsion technologies should be revisited 
because they have the potential of solving the 
“Shuttle Dilema“ for a class of users that can 
bring significant benefit to the space program as 
a whole. 


(1) WSewman, Daniel D., Study of the Water 
Electrolysis Propulsion System- Pinal Report, 
Engineering Record No. 151, Hughes Aircraft Co., 
S.S-D., Propulsion and Power Systems Laboratory, 
5 June 1964. 


(2) Water Electrolysis Rocket, Hughes 
Aircraft Company Proposal, 63H-7438/9419 (Dec. 
1963). 


(3) Blectrochemical Service Unit, Hughes 
Aircraft Company Proposal, 64N-2115/A3951-801 
(April 1964). 
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Thoughts On Level Three 


by Lynn W. Taylor, WBGUUT 


Yea, from the table of my memory 
L'll wipe away all trivial fond records. 
-- Hamlet (Act I, Scene 5, line 98) 


According to the Iso Open Systems 
Interconnect model, the network controllers are 
responsible for the first three of the seven 
protocol layers ina packet switched network. 
Layer 1, the Physical level, is responsible for 
the physical aspects of communication (radios, 
modems, HDLC, baud rates). Layer 2, the Data Link 
level, is responsible for taking the physical 
medium and making it error-free, and dividing 
it up among the users. The third layer, called 
the Network, or Communications Subnet level 
determines the hoste-subnet interface and how 
packets are routed in the subnet. Levels 4 
through 7 deal with issues that are beyond the 
scope of this paper. 


Routing is one of the key issues when 
defining a Communications Subnet Level protocol. 
The various routing algorithms can be divided into 
two categories, centralized (where some central 
station must know or discover the network 
topology, and serve as a clearinghouse for 
routing) and decentralized (where each TNC can 
handle at least part of the routing task). 
Centralized algorithms must be designed to 
Yecover when the master station crashes, and each 
station must know how to reach the router itself. 
Decentralized algorithms require each station to 
know how to pass traffic to other stations in the 
net; to accomplish this, the TNC needs to find out 
something about the nework topology. 


Iam going to discuss two specific routing 
algorithms, the advantages and drawbacks of each, 
and why I believe we should select a decentralized 
algorithm for Amateur use. None of this material 
is original, and most is discussed at some length 
in the computer science literature. Some of the 
combinations of this information are new, 
particularly as they relate to the specific 
problems of Amateur usage. 


The first algorithm has a couple of advan- 
tages, and one major disadvantage. This algorithm 
does not require any special knowlege of the 
network topology, other than a list of stations 
that the TNC can hear. When the TNC receives a 
packet addressed to someone other than itself, it 
simply passes it on to everyone it can hear 
except the station it received it from. The 
algorithm is appropriately called Flooding. 


Flooding is easy to understand, and easy to 
implement. The problem comes when the load on the 
network increases. Since each packet will pass 
through every single node in the network, and 
many of them more than once, the amount of 
traffic generated by simply saying “Hi" can be 
etaggering. Also, steps must be taken to prevent 
packets from looping forever through the network. 
The simplest case of this is a 4 station net (A, 
8, C and D) where all 4 stations can hear each 
other. If A originates a packet for D, it passes 
it to all 3 atations it can hear. B passes it 
to both C and D, where D accepts it, and C passes 
it to A and D. D has already got the packet and 
ignores the duplicate, while A passes it to B 
and D. Again, D discards it, and B passes it 
around, At the same time, packets are flowing 
in the opposite direction around the same loop. 
While this simple case could be easily fixed, it 
becomes more complex ina larger net. One 
solution is to limit the life of any given packet 
to a certain number of hops, but this still 
generates a lot of unnecessary traffic. 


A better algorithm would require each TNC 
to have a table giving the address of each node 
in the network, some measure of the distance to 
that station, and the address of the next station 
along a path to that station. A hypothetical 5 
station net, and each node's tables is shown 
below: 


A <-2=) B tne"? € <---> D <--=> E 
Bil sB AlA A28B aAgcC A4D 
C28 clic B1B B2c B3D 
D38B D2c Dib cic c2D 
E48 E3c E20D E1E Diob 


In this example, the available communica- 
tions paths are shown by arrows (i.e. A cannot 
communicate directly with ¢C). Note that each 
station knows how far away all the other stations 
are, and who is the next station in the chain. 
If A wants to talk to D, A knows to pass traffic 
to D, and it will take 3 hops to get there. It is 
up to B to know who to pass these packets on to. 


The problem with this method is easy to 
see -- where do these tables come from? In the 
proposed WestNet protocol, which defines a_  long- 
haul network for linking geographically seperated 
LANS, a similar algorithm is used which assumes 
all nodes internal to the network will stay on. 
In other words, this network is static (because 
all the nodes are dedicated devices to be 
installed on mountaintops). In a local network, 
stations (nodes} tend to appear and disappear 
frequently. 


In a dynamic network, the answer to the 
question must be "from the network itself.” 
This further divides into two problems: how does a 
new station get it's initial table, and how do we 
make sure the table each node has is up to date. 
To clarify this problem, lets add station F to our 
earlier network: 


A Se-=? 8B Come? C Come? D CH==> E 


oecnenne wamwe> F Cemnmnnnnnnnce 


In this example, A should now pass traffic 
for E through F, while traffic for D can follow 
its previous route, or as efficiently through E 
and F. If all stations listen for new stations 
on the air, and F comes on and sends an “I'm here" 
(or CQ) packet, A and E can detect F's presence, 
connect with F to make sure they can communicate, 
and pass copies of their routing tables. By taking 
the best information from both tables, F can 
build it's initial table: 


Hoawr 
ePNWNe 
nnn > > 


There are two equally good paths from F to C 
{through E and D, and through A and B), F selects 
these at random. 


Also, the rest of the net need to be told 
about the new network topology. First, A (and 
simultaneously, E) telis everyone it can hear that 
F is one hop away from it. B checks it’s routing 
tables, decides that this is good news, and passes 
the news along to everyone it can hear, etc. This 
is the flooding algorithm again, with a twist: 
stations only pass on good news, so if a station 

(continued on page 19) 
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already has a path of length N, it only passes 
On news of a path of N-1. In other words, when B 
announces to A and C that “I'm 2 hops from F", C 
is glad to hear, while A could care less, since A 
is only 1 from F, while C didn't even know PF 
existed. C will wind picking the first path to F 
it hears about, since it has 2 paths of length 3 
to F. This also means that C might use a 
different path to F than F would use to C; this 
does not matter since each have the same length. 


F would also pass on the news of it’s 
complete routing able, since the whole table is 
news to it. This way, A learns of the new path 
through F to £ and E learns about it's new paths. 
The new tables would look like this: 


BlB ALA A2B A3A A2F 
c2B8 cic BiB B2C B3D 
D3B pbD2cC DID ¢Clc¢c c2D 
E2F £€3C £2D ELE DloD 
PLP P2A P3A P2E FIP 
A <en-> B C22? C Co-=> D Cwoer £ 
J \ 
owe eee. wewe> FP Cneecnnnnnnnn= 

ALA 

B2A 

C3E 

O2E 

ElE 


Adding a node to the network is easy 
compared to what happens when a node leaves the 
net. Having a node tell the net it's leaving is 
impractical, because that node may not be able to 
tell the net because of hardware failures, power 
failures, or propogation changes. One solution 
would be for a node to report to the rest of the 
net that node X is unreachable whenever it can't 
pass traffic on to X. This bad news would be 
passed through the net until it reaches X, which 
would then tell those stations it can still 
reach that it is indead still reachable, 
generating a new set of entries in the network 
tables. 


As an example, A is passing traffic for E 
through F when F goes off the air. A, realizing 
that it can’t pass traffic through F announces 
to B that E is unreachable. B passes this news to 
C, who passes on to D, and eventually to E. At 
this point, E has been erased from everyone's 
routing tables. E would then tell D “I'm still 
accessable“, D reports to C that “E is still 1 
hop from me", and the good news passes through 
the net (and contradicts any bad news still 
circulating). A may now use the longer path 
through B, C and D, and the network has recovered 
from the loss of the path to E through F. 


The problem of updating the routing tables 
is the most serious drawback of this algorithm, 
and I am not suggesting that the method I have 
explained above is the best. In Computer Networks 
by Andrew Tannenbaum, he points out that “good 
news travels fast” while bad news may take awhile 
to propogate through the network, especially 
where looped paths exist. By completely 
eliminating &@ atation from the network tables 
and te-inserting it, many of these kinds of 
problems may be avoided. 


I have explained two decentralized routing 
algorithms. These algorithms allow the nodes 
themselves, on an equal basis, to decide how to 
route data in the net, and dynamically alter the 
routing when the network composition changes. 
What are the problems involved in a centralized 
algorithm? 
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Centralized algorithms require a single 
station to have complete knowlege of the network. 
To do this, the master station must probe the 
network, and pass on it’s discoveries to the rest 
of the net. The master must either be a unique 
station type, or, in a homogeneous network, a 
station must be selected to be the master. A new 
station, when it comes on the air, must be able to 
tell the master it is on, and, if it can’t reach a 
master, would most likely become one. Problems 
exist, in the case of two networks “growing™ 
together (more than one master), and when the 
master fails. Depending on the implementation, 
a network may continue to operate without the 
master based on old information the master distri- 
buted, or collapse when the master disappears. 
Either solution would be undesirable. 


I have shown that a properly designed decen- 
tralized system will not suffer unduly from the 
loss of any single critical station, and recover 
from the loss of any node in a reasonable manner. 
Centralized systems rely on the master station 
@iscovering the complete network topology, finding 
changes due to propogation, etc. and distributing 
this info. Since Amateur packet nets are very 
dynamic, it is probable that the master will be 
lost, causing the net to crash, or continue on 
without any direction. 


While I feel the decentralized approach 
is best, the possibility of reasonable mechanisms 
for operating centralized networks, hybrid net- 
works, rings, token passing schemes, and others 
are all worth investigating. My main purpose is 
to serve as a catalyst for further discussion. 
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“Join The Packet Revolution” has been our 
slogan for some time and most of you are now a 
part of that revolution. How do we know? = Chuck 
Green, NOADI, reports that he just put serial 
number 1417 on a TNC PC board! 


A revolution requires people dedicated to a 
cause; we have that. A successful revolution 
requires a growing number of people supporting 
that cause. It seems to us that the above number 
is a good indication that we also have that! 


Have you noticed an increase in Packet 
activity in your area? Many ares of the country 
are experiencing a rapid growth rate. More and 
more people are asking “what is Packet Radio?” or 
“what is that abrasive sound?”, etc. 


An increasing amount of coverage in the 
national Amateur _ Radio publications has also 
heightened interest. Many local clubs are looking 
for people who know what Packet Radio is to give a 
demo and/or presentation at a regular meeting. 
Why not take your packet station to a local club 
meeting {clear it with their program chairman 
first) and give a demo? It is even more effective 
if you take two stations although a pre-arranged 
sked with someone at their home QTH is good. 


Digipeating through another station back to 
yourself, although not very practical in normal 
situations, makes for an interesting demo of digi- 
peating. There are lots of other interesting 
ideas for demos that I am sure you can think of. 
You will find that a simple demo and/or 
presentation on Packet Radio will quickly result 
in requests for more. You will also find that the 
result will be an increase in Packet Radio activity 
in your area. 


If you do plan such an activity, write TAPR 
well in advance 80 we can send you some literature 
to give those who show interest. We hope you will 
give this a try, it really is a lot of fun. 


Th ee 5) 


Satellite Coordination 


A meeting of many of the national groups 
interested in the construction of amateur 
satellites was held during the period June 32 
through July 3 at Hotel de la Bere in the 
vicinity of Cheltenham, England. In attendance 
were the following invited representatives: Ian 
Ashley ZLIAOX, Dick Daniels W4pUJ, Robin Gape 
G8DQX, Bandi Gschwindt HASWH, Werner Haas DJSKQ, 
Gordon Hardman KE3D, Phil Karn KA9Q, Jan King 
W3GEY, HansPeter Kuhlen DK1YQ, Karl Meinzer DJ42ZC, 
Harold Price NK6K, Randy Smith VEISAT/VE6, Martin 
Sweeting G3YJO and Dave Woodhall ZS6BSNT. Not in 
attendance were invited representatives from the 
technical groups of JAMSAT and RACE. 


On the agenda were the following main items: 


(1) Review of AO«-l@ performance and future 
scheduling of spacecraft operations. 


(2) Review of the PACSAT mission. 
(3) Review of the UO-l1 spacecraft status. 


(4) Review of the Ariane-4 launch 
opportunity. 


(5) Review of new tectinologies required for 
future amateur satellites. 


Due to the final orbit obtained by A0-10, 
a set of operating procedures were required 
that would deal with the upcoming eclipse and 
sun angle constraints expected over the next two 
year veriod. The schedule selected is responsive 
to the reduced power per orbit and the requirement 
to off-point the satellite from its optimum 
attitude in order to minimize thermal and power 
effects caused by poor sun angles. At the same 
time attempts were made to respond to a variety of 
user operating requests. 


A modified general beacon (145.812 MHz) 
schedule was also adopted the more egually shares 
time between Morse code, 508 baud RTTY and 400 BPS 
PSK telemetry and reduces the time between 
successive transmissions of any type. 


The details of these schedules will be 
announced by usual amateur satellite society 
sources within the next few weeks. They will be 
in effect by early August as this is the time 
required to finalize the spacecraft maneuver and 
implement the needed software. 


Regarding future changes to the satellite's 
schedule, the amateur satellite technical group 
present adopted the following proposal for 
review and adoption by the world wide amateur 
satellite societies: 


PROPOSAL FOR THE FORMATION OF AN INTERNATIONAL 
AMATEUR SATELLITE SERVICE COORDINATION COMMITTEE. 


This group, recognizing that: 


(1) The launch of a satellite system 
represents the creation of a significant resource 
for the use of all radio amateurs; 


{2) The mission requirements of the groups 
providing a new satellite system are of primary 
importance; 


(3) The operational aspects of the amateur 
satellite service must be carefully identified, 
planned and managed; and 


(4) The freedom of the individual national 
and international groups to negotiate and plan new 
missions independent of external constraints must 
be maintained, 
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Proposes the formation of an international 
amateur satellite service coordinating committee, 
whose mandate shall be to: 


(1) Establish technical and operational 
standards for the amateur satellite service; 


(2) Plan and coordinate the orbital 
operations of each portion of a system which may 
be released by the groups which launched the 
system; and 


(3) Interface with the International Amateur 
Radio Union to ensure that the best interests of 
all radio amateurs are given due consideration in 
this planning process,: 


And further proposes that membership in this 
committee be limited to those groups who have as a 
primary interest the provision and utilization of 
amateur satellite services, as evidenced by their 
charters or constitutions, and to such further 
groups as the committee shall determine advisable. 


No decisions regarding PACSAT were taken by 
the assembled group. Considerable discussion was 
held concerning the need for coordination of 
packet radio standards world wide. Considerable 
concern was raised that the JAS-1 packet 
experiment is unlikely to be compatible with the 
PACSAT standards on the basis of data rate and 
modulation type. In general, it was felt that more 
work was necessary to adopt true international 
standards for this mode of communications. 


No decisions regarding U0-11 were taken by 
the assembled group. M. Sweeting reported that 
the spacecraft would be put into service and the 
experiment program initiated as soon as the boom 
deployment was complete which was expected in 
approximately two week's time. [Boom was deployed 
successfully 27 July.--Ea.) 


The Ariane-4 launch opportunity was reviewed. 
ESA has offered AMSAT-DL a firm launch contract 
for 2960,0800° European Accounting Units on the 
Ariane-4 test launch. The contract is expected to 
be signed in late July. 


Three candidate missions were discussed. 
These included an Astroid encounter probe, an 
advanced Phase-4 satellite system concept and a 
modified Phase-3 satellite. The first two 
candidates were given lower possibility of success 
due to time and fiscal constraints. This is 
particularly true due to the high launch cost 
being imposed by ESA on this launch. The Asteriod 
encounter probe was not discussed further. The 
Phase-4 concept presented by W3GEY was given 
serious consideration for future opportunities and 
W3GEY, DJ4ZC and G3YJO will continue to discuss 
and define this concept. 


The Phase-3C satellite to be incorporated on 
Ariane-4 will contain all of the hardware included 
aboard AOQ~18 but with the following additions or 
modifications: 


(1) A modified kick motor using a plasma 
propulsion technology. . 


(2) A modified Mode-L transponder with improved 
efficiency. 


(3) An S-Band beacon experiment. 
(4) A packet radio and beacon unit. 


The latter unit will be a store-and-forward 
device with approximately 1 megabyte of memory. 
In addition, it may have a mode of operation 
allowing straight regeneration of data as would be 

(continued on page 24) 
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Hams In Space 


Apparently the Hams~In-Space theme will have 
periodic reprise throughout the second third of 
the decade as NASA has selected Dr. Ron Parise, 
WA4SIR, to fly as Payload Specialist on at least 2 
future shuttle missions! 


Ron was notified on 11 Jun 84 of his 
selection. In an exclusive interview with ASR 
last week, Ron indicated he had applied for the 
position in Sep 83 and was delighted at his 
success. He is anxious to include Amateur Radio 
activities in the mission although he cautions, 
“This will be a crew-intensive mission” referring 
to the projected March 1986 planned launch of 
Mission 61F. The 61F mission will be a further 
flight of the Spacelab series. 


Dr. Parise is an astronomer with a PhD from 
the University of Florida (1979) and is 33 years 
old. He has been a licensed amateur since he was 
11 having held prior calis WN8JBR and WASMHD. Ron 
is a native of Warren, Ohio, is married and has a 
young son. He and his wife, Cecelia, are 
expecting another child, 


The newest astronaut-selectee is employed by 
Computer Sciences Corporation in their Systems 
Sciences Division and currently lives in Silver 
Spring, Maryland not far from AMSAT Headquarters. 
Ron is an active AMSAT member and frequently gives 
talks and presentations on science aspects of 
OSCAR. He has been AMSAT's Science Coordinator 
for the U0-9 mission. Computer Sciences is under 
contract to NASA and in fact Ron works at the 
Goddard Space Flight Center at Greenbelt, 
Maryland. 


The 61F mission will carry the ASTRO 1 
experiment in its Spacelab section. This 
experiment is sponsored by NASA‘s Office of Space 
Science Applications and involves an ultraviolet 
imaging telescope. Ron helped design the 
instrument and will be aboard to operate it and 
collect data. He also is involved in two later 
follow-on experiments known as the “Hopkins 
Ultraviolet Prime Focus Spectrometer" developed 
in conjunction with Johns Hopkins University and 
the “wisconsin Ultraviolet Photo Polarimeter" 
developed in conjunction with the University of 
Wisconsin. ASTRO 2 (Hopkins Spectrometer) is due 
for launch in Nov 86 while ASTRO 3 (Wisconsin 
Photo Polarimeter) is slated for Jul 9&7. Ron 
indicates his contract with NASA calls for him 
flying two missions and being a backup for the 
third. 


Regarding his operating Amateur Radio from 
the shuttle Ron says he is “enthusiastic” and 
looks forward “to bringing some radios aboard". 
Ron says he will support proposals to NASA for 
Amateur Radio activity on the missions he will be 
flying but because of intense preparations for the 
science aspects of the mission, will be unable to 
spearhead the proposal effort. He indicates full 
support for the premise without hesitation, 
however. 


The Amateur Space program has its roots 
firmly planted in space science. AMSAT is a 
remarkable alloy of scientists, engineers, 
educators and layman reflecting the very best in 
Amateur Radio. We are justly proud that “one of 
our own” has been selected to carry space science 
further along new paths and will be carrying 
Amateur Radio along just to keep in touch! 
Congratulations to Ron, WA4SIR! (And to us, too). 


Dr. Tony England, WORE, is due to fly the 
shuttle in March 8&5 and@ an ambitious proposal was 
jointly submitted by ARRL/AMSAT recently to permit 
Tony to follow the lead of Owen Garriott, W5SLFL, 
and Owen's historic 1983 premiere Ham-In-Space 
effort. 


KAKKKKK 
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JAS-1 Update 


JAS-1 is now in its EM/PM phase. JAMSAT has 
to complete FM #1 modules by the end of August 
(this year!), when NEC will commence tests to see 
if JAMSAT made units fit to “buss” of the 
satellite they produce. Final acceptance test 
including thermal vacuum test is scheduled in 
Pebruary next year. Test for FM #2 will be some 
six months later. 


JAS~1 makes use of the only micro~-computer 
system in it as IHU as well as PACSAT like 
“flying mailbox”. 


JK1VXJ_ successfully made "no ROM bootstrap 
loader“ for NSC-808 up and running late in April. 
It was a great milestone for us, since we had 
regarded that the most critical-path in develop- 
ment of the micro-computer system of JAS-1. 


We have received PCBs of the memory system 
for FM#l. They will be populated shortly. 48 
chips of 256K DRAMs will be put into 1 flight 
model. We have mostly completed series of 
radiation tests on NMOS (256K DRAM) and high- 


speed CMOS. The former survived well up to 
50@8 RADs. In fact, we can't tell “radiated 
(5@@@ RADs)" chips from "new" ones. It was 
beyond our expectation, or imagination. On the 


other hand, some high- speed CMOS devices were 
found “dead" at S888 RADs. 


These results made us worry a bit. Design of 
anti-radiation system in JAS-1 was based on 
our belief that the most fragile component 
should be N=-MOS DRAM, not high-speed CMOS. 
DRAMs were “expected to die“ at around 1990 RADs. 


was made clear that high-speed CMOS or 
Nsc-808 (which is said to die at aroundL 500 RADs) 
needs more shielding than DRAMs. In order to give 
longer file to JAS-1 than previously planned, we 
decided to change the measure of selctive- 
shielding on chips of these types. 


A semiconductor designer in JAMSAT was also 
surprised at the results mentioned above. 
Per his request we made another series of 
radiation tests on 18 NMOS DRAM chips, up to 
$9,008 RADs. We'd soon know their real break-down 
point. The result of these tests would he of 
some use for PACSAT and Phase-3C, which might 
also employ NMOS DRAM of this sort. 


Development of H-) rocket has been 
paving the way as expected. There should be 
no delay of launch, which is expected to be on 
4th. February 1986. 


A potential “source of problem" (which 
I personally suppose to be) stems from the 
failure of BS-2a, our initial DBS for public on 12 
GHz. It was launched in February this year. As 
you might have known, two (out of three) TWTs in 
that satellite have gone out of order within 
three months. Our national broadcasting organiza- 
tion was hence obliged to commence the service 
only with one channel instead of two. 


Because of nature of the failure, they now 
seem reluctant to launch its back-up satellite of 
the same design (including Thomson-CsF made 
TwTs) as scheduled in August next year. 1€ 
they want to postpone the launch in order to 
make some modification, (since we can only 
launch satellites twice a year, in February and 
August) there is a good chance that the launch 
of BS-2b would be made in February 1986. 


In that case, demonstration flight of H-1, 
which will put JAS-1 into orbit should be delayed. 
NASDA can not prepare two launchers (N-II_ for 
BS-2b and H-1] for JAS-1 in this case) for the 
same period. 
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Packet - A Software Approach 


by Bob Richardson, W4UCH 


Writing a squib about the software approach 
in the Tucson Packet Status Register is much like 
the Little Red Hen's acceptance of Brer Fox's 
invitation to dinner. There is no question that 
it will be an outstanding gourmet meal. There is 
little doubt as to exactly what the intended entre 
will be. I am unsure whether to feel like the 
Little Red Hen or a wolf in a chicken feather 
suit. No never mind, let's press on, 


Seriously, packet radio is a house of many 
mansions. There is room for all types and 
varieties of radio amateurs from those who like to 
grind their own crystals (and mine their own 
galena), up to and including those who prefer to 
purchase one of Mike Lamb's (Advanced Electronic 
Applications, Inc.) superb factory built and 
tested PKT-1 packet radio controllers (from the 
TAPR design). Let me tell you about the joys of 
the "mining galena" approach to packet radio. 
Really, it is not quite as fundamental an approach 
as all that since we will be using a store bought 
Model 1, 3, or 4 TRS=80 microcomputer and we will 
not reinvent the wheel by recasting in silicon the 
EXAR 2206/2211 AFSK modulator and demodulator 
chips. 


In late 1981, early 1982, we became fasci- 
nated with the packet activity of our Canadian 
Cousins across Lake Erie from our QTH in the 
southwestern corner of New York state. With two 
22 element Cushcraft Boomer 2 meter antennas we 
were able to copy southern Ontario packet stations 
running the Vancouver protocol about 75% of the 
time with S5 or better signal levels. Considering 
the distance involved was is in the 80 to 120 mile 
ballpark, a bit of "knife edge" refraction was 
thrown in to help as most VE3 stations were 
running about 10 watts to omnidirectional anten- 
nas, 


Since we had just finished writing a series 
of textbooks on the software approach to Morse, 
Baudot, and ASCII teletype programming, it was not 
too surprising that the idea of using the software 
approach for synchronoua 1200 baud packet occurred 
to us. With the encouragement of that packet 
pioneer, Stewart Beal, VE3MWM, and umpteen phone 
cail arranged schedules, we were able to develop a 
program that emulated in software most all of the 
features of the Vancouver terminal node controller 
at 1200 baud. It was a step by step process and 
consumed all of 1982 to complete the first packet 
software program. Our gocd friend, Gil Boelke, 
W2EUP of GLB Electronics joined the fray on New 
Year's Day of 1983 and from there on, our weak 
signal and fading problems ware over as Gil is 
only about 50 miles distant, just south of 
Buffalo, NY. 


The March 1983 release to the public of the 
AX.25 protocol was greeted with the same 
enthusiasm by many Vancouver buffs as bubonic 
plague. Many have still not fully recovered. 
Also, our software approach was greeted by many 
hardware approach buffs with similar enthusiasm at 
the 2nd ARRL Amateur Radio Computer Networking 
Conference in San Francisco during March 1983. 
So, what else was new? 


The logic and beauty of the AX.25 protocol 
grows on one if one is willing to keep an open 
mind and look at the woods as a whole while 
ignoring the few brambles amongst the trees. We 
became a born again AX.25 zealot shortly after the 
San Francisco unveiling and began writing Volume 2 
of the software approach - AX.25 protocol the 
summer of 1983. With the constant aid, abetment, 
and almost daily testing with WZ2EUP we were able 
to finish Volume 2 by year end, 1983. 
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Volume 1, Vancouver protocol, worked quite 
well, but had two serious drawbacks: 


1. The cyclic redundancy check (CRC) was an almest 
exact software emulation of the IBM SDLC CRC which 
was done using the bit by bit approach and when 
long multi-frame packets were received, one or two 
of seconds of delay was required to accomplish the 
CRC check. 


2. The received data was stored in memory on a bit 
per byte basis which was a great teaching tool; 
i.e., using the edit/modify mode one could display 
a 1024 byte screen of memory and see the flag 
bits, data bits with zero insertion where 
applicable, and closing flag(s). This was delight- 
fvl, but consumed precious memory like a monster 


In Volume 2 we overcame these drawbacks. The 
first was overcome through the help of Aram Perez 
who published the “Byte-wise CRC Calculations® 
paper in the June 1983 issue of the IEEE Micro 
Journal. By modifying this program for the CRC 
polynomial used by both the Vancouver and AX. 25 
protocols, the CRC check was speeded up an 
incredible 27 timea faster than our bit per byte 
original approach. The second drawback was 
overcome by using W2ZUP's brilliant real-time 
synchronous to 8 bit parallel byte conversion 
subroutine with a . few of our own modifications, 
Only the converted data bytes between flags were 
stored in memory along with the last opening flag 
and closing flag MEM locations for each frame. 
The momory monster had happily evaporated into 
thin air or gone wherever scrolled off bytes go. 


Volume 2 - AX.25 protocol first printing was 
shipped in January 1984 and received a kindly 
write up in the February 1984 OST. The OST write 
up plus our overseas distributors’ good efforts in 
advertising gave it the kick off impetus any new 
book on such an esoteric subject sorely needs, 


The 3rd ARRL Amateur Radio Computer Network- 
ing Conference was held in Trenton, NJ during 
April 1983. The conference proceedings include 
35 pages of our software approach subroutines and 
is available from ARRL for $10 postpaid if you 
want a truly inexpensive introduction to the 
subject. Other papers by many TAPR, AMRAD, et al 
friends, are well worth reading too. If you do 
not have a copy of the proceedings, you should 
order one from ARRL. 


Volume 2 - AX.25 protocol second printing was 
received from the printer during July 1964, Its 
claim to fame, other than having obvious typos 
corrected, is an additional 32 page Appendix 7 
added that covers: 


- Overlapping WINDOWs over the main menu a la this 
rather popular feature on some computer programs 
that seem to be taking the world by stor. It 
does not make the program run any better, but it 
sure looks nice and misleads the reader into 
thinking we know what we are doing. 


- Multiple repeater input if desired. Up to 100 
repeaters may be input if this feature suits 
your fancy. Conversely, up to 100 repeaters in 
the extended address field are automatically de- 
coded and forwarded if your call and SSID are 
there. 


- Optional automatic beacon mode in addition to 
the optional auto connect/disconnect mode. This 
idea is a direct steal from ‘TAPR' and a nice to 
have feature. With both the beacon & auto modes 
toggled ‘ON’, the program in your absence will 


(Continued On Page 23) 
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Official Supplier of TNC’s To The 1984 Olympics 


by Ted Harris, N611U 


The 1984 Olympic Soccer matches were the 
first use of Packet Radio during an Olympic event. 
The Olympic Committee wanted delivery of phone 
messages over a two mile distance. 


The Palo Alto Chapter of the Red Cross was 
already involved with the Olympics and decided to 
help solve the problem. When the subject of hard 
copy messages via a radio circuit was discussed 
loud cries of; we don't know how to. run 
computers," “we don't want a complicated system," 
and "how much will it cost" were heard. When told 


Games of the 


this was a free experiment, they seemed resigned 
to the willingness of this group of radio amateurs 
to do anything to solve problems. 


Once installed (and after only short five 
minute training sessions) the system worked 
flawlessly until a secretary came over and said, 
“I thought you said this thing worked. Well it's 


broken, hurry up and fix it. We depend on it!” 
The board was swapped and the system returned to 
24 hour a day operation for 11 more days. Over 


1388 messages were sent with many hours saved. 


Football 


XXHlrd Z 
on hnpies 984 July 29-August 8 
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transmit "THIS IS WIABC IN AUTO AND BEACON MODE. 
IF YOU WISH TO LEAVE A MESSAGE, FIRST CONNECT, 
LEAVE THE MEASSAGE, AND THEN DISCONNECT. WILL 
BE BACK AT 8:30 PM," When NOT connected, the 
beacon timer will retransmit the beacon message 
every 5 minutes or at any interval you wish. If 
someone connects to you in auto mode and is not 
active for a 5 minute period, the program will 
automatically disconnect and restart the beacon 
timer countdown, 


- Addition of a simple subroutine for loading the 
the user's call letters into the concatenated 
program one time only. The permanent program is 
then dumped to disk one time only. No Gridley, 
you do 'NOT' have to been an assembly language 
programmer to use the program, but you MUST know 
how to insert the disk into one drive and close 
that disk drive's door. Figure 1 illustrates the 
main and shift menus of the program without the 
new windows overlay. 


The future of the software approach looks 
rather promising from three directions. 


1. Remote low power repeaters as in satellite or 
in mountain top repeaters. Using a CMOS version 
of a 2-80 with CMOS ancilliary chips and memory 
offers an order of magnitude or more reduction 
in total power consumption over the hardware 
approach with its own dedicated packet micro- 
computer, sometimes called a packet controller. 


2. Parallel, data-flow, and/or pipelined non-Von 
Neuman computer architecture using dual micro- 
processors ona single chip, but sharing the 
same accessible though segmented memory, offers 
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the software approach full duplex operation, if 
that is your pleasure. The dual 6502 micro- 
processors on a single chip are now available 
and the dual 2-808 on a single chip are not 
too far down the pike. 


3. The new 2-800 microprocessor with its built in 
cache memory and pipelining offers the software 
approach the capability of running 9600 baud 
initially with its 10 MHz clock and growing to 
19,2K baud in about a year when the 2-800 clock 
grows to 25 MHz. Incidently, the only thing 
better than one Z-800 are two Z-800s. With two 
of these rascals sharing a single memory, yes 
it is easily implemented, you can virtually re- 
invent the world in your own image if you wish. 
About the only limit is your own imagination. 


Want to dig deeper into the software ap- 
proach? If so, our 280 pagé Volume 2 - AX.25 
protocol is available for $22 (US) postpaid in the 
U.S. and Canada from: Richcraft Engineering Ltd., 
#1 Wahmeda Industrial Park, Chautauqua, NY 14722 
or phone (716) 753-2654 for COD orders, Por 
overseas orders and/or forthcoming French and 
German language editions, write Richcraft. 


Here at Richcraft on the shore of beautiful 
Lake Chautauqua we have the highest admiration for 
the Tucson Amateur Packet Radio group led by Lyle 
Johnson, WA7GXD. TAPR's dedicated team has 
virtually accomplished the impossible with only 
invisible assets. Nevertheless, those invisible 
assets of truly hard work, dedication, and 
selfless contribution to the advancement of 
amateur packet radio have been of inestimable 
value and earned the TAPR team the world 
leadership they so richly deserve. 
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(continued from page 20) 

of use by gateway nodes internationally. The same 
unit will be capable of using the large memory for 
storage of beacon messages which will be 
transmitted in 360 or 1286 bps FSK or PSK. The 
packet mode is expected to use 2400 bps PSK. 


The Phase-3C satellite will be constructed by 
all of the groups attending the meeting. Work 
assignments were made so that pregress on the new 
satellite may begin immediately. 


A variety of spacecraft technologies were 
discussed during the last day of the conference. 
The intent was to identify technologies needed for 
future amateur satellite missions. Included in 
the presentations were propulsion technologies, 
attitude control technologies and improvements in 
ranging/orbit determination technology. 


It was felt by most of the participants that 
the meeting accomplished its intended objectives 
and was much needed. The conference again 
demonstrated the value of international coop- 
eration and participation as the amateur satellite 
service matures. 
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(continued from page 5) 

That's the list as I know it to be. Submit 
any others to the TAPR PO box. Now that we've 
got a secretary, hopefully they won't get lost. 


Remember, the TRACE command ig handy for 
looking at the protocol and seeing exactly what 
the TNC sent/received, including user data. 
Please include hardcopy of traces for protocol 
error reports. 


KKKKKKK 


The Tucson Amateur Packet Radio Corporation 
is a nonprofit scientific research and development 
corporation. The Corporation is licensed in the 
State of Arizona for the purpose of designing and 
developing new systems for packet radio 
communication in the Amateur Radio Service, and 
for freely disseminating information acquired 
during and obtained from such research. 


The officers of the Tucson Amateur Packet 
Radio Corporation are: 


Lyte Johnson ..... WA7GXD ... President 
Heather Johnson .. N7DZU .... Secretary 
Chuck Green ...... N@ADI .... Treasurer 


The Packet Status Register is the official 
publication of the Tucson Amateur Packet Radio 
Corporation. Explicit permission is granted to 
reproduce any material appearing herein, providing 
credit is given to the author and TAPR. 


PSR Mailing address: (For PSR editorial material 
Minnesota Amateur Packet Radio 
c/o Pat Snyder, WASTTW 
University of MN Computer Center 
208 Union Street S.E. 
227 Experimental Engr. Bldg. 
Minneapolis, MN 55455 


via CompuServe: 70225,1252 


TAPR HF Net: 
21.280 MHz 7.188 MHz 
198662 Sundays 218002 Sundays 


The Packet Status Register is edited and prepared 
by the following members of the MAPR group in the 
Twin Cities using material contributed from 
wherever we can get it: 


Pat Snyder ...... WAOTTW 
Paul Barnett .... NOCRN 


Tucson Amateur Packet Radio Corporation 
P.O. Box 22688 
Tucson, AZ. 985734 


Check YOUR address label for 
membership EXPIRATION date I 


